Message-ID: <4D9A295A.1000005@gmail.com>
Date: Mon, 04 Apr 2011 13:26:02 -0700
From: Daniel Colascione <dan.colascione@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: Utility: injob
References: <4D995AA9.9090909@gmail.com> <BANLkTimhze=K4yrTqLd-CWvfqVw1CCB7HA@mail.gmail.com>
In-Reply-To: <BANLkTimhze=K4yrTqLd-CWvfqVw1CCB7HA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

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