This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Utility: injob

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: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]