X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_VC,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By:	sourceware.org
Message-ID:	<4D9A295A.1000005@gmail.com>
Date:	Mon, 04 Apr 2011 13:26:02 -0700
From:	Daniel Colascione <dan DOT colascione AT gmail DOT 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 AT cygwin DOT com
Subject:	Re: Utility: injob
References:	<4D995AA9 DOT 9090909 AT gmail DOT com> <BANLkTimhze=K4yrTqLd-CWvfqVw1CCB7HA AT mail DOT gmail DOT com>
In-Reply-To:	<BANLkTimhze=K4yrTqLd-CWvfqVw1CCB7HA@mail.gmail.com>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT 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

- Raw text -