On 4/4/2011 12:39 AM, Andy Koppe wrote:
On 4 April 2011 06:44, Daniel Colascione wrote:
Attached is a small program that runs a set of processes under an NT job
object, allowing you to stop, resume, and kill them using normal Cygwin
job control --- whether or not these processes are Cygwin programs.
Very nice. One issue I frequently see with mintty (and any other
pty-based terminal) is with trees of native processes, e.g. a Visual
Studio build through vcbuild. ^Cing it in mintty kills the top process
point blank (via TerminateProcess), which means its child processes
continue to run. Your utility appears to address that.
That's precisely the situation I created the tool to address, though I
haven't tested it with vcbuild in particular. According to the
documentation, vcbuild should work under a job object on any OS newer
than Win2k.
Could its approach be used in the Cygwin DLL?
Doubtful. Essentially, your proposal would be to use process objects to
implement process groups that could incorporate non-Cygwin processes.
The problem is that there's no clean way to integrate with other Windows
job objects and process groups: there's no way to tell that a non-Cygwin
process was created a child using CREATE_NEW_PROCESS_GROUP and should be
excluded from the job. Even if we could receive such notification, it'd
be too late because processes cannot be removed from jobs. Furthermore,
a process can only be in one job at a time, which, as I mentioned in my
first email, may cause programs that rely on job objects internally
(like IE) to malfunction when run this way.
One could use a job object with the JOB_OBJECT_LIMIT_SILENT_BREAKAWAY_OK
property set. In this mode, processes in a job don't cause subprocesses
to inherit that job. That would allow Cygwin job control to work for
one non-Cygwin process, but not its children. But for this application,
you don't need job objects at all: a Cygwin surrogate process could just
handle SIGTSTP itself. I'd like to see this behavior, if only so I can
^Z a Win32 process I'd forgotten to run with &. But it seems to be of
limited usefulness.
In short, using job objects as injob does is a workable hack that can
help certain workflows, but I wouldn't recommend making it default
Cygwin behavior.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
