Re: why does NSTask setpgrp on sub processes?

[Richard Frith-Macdonald]

On 20 Jan 2010, at 07:21, Derek Zhou wrote:

> On Tuesday 19 January 2010 10:14:15 pm Derek Zhou wrote:
>> On Tuesday 19 January 2010 12:59:28 am Derek Zhou wrote:
>>> hi all,
>>> it seems NSTask setpgrp after the fork:
>>> ...
>>>      /*                                                                     
>>>    
>>>       * Make sure task is run in it's own process group.                    
>>>    
>>>       */
>>> #ifdef     HAVE_SETPGRP
>>> #ifdef  SETPGRP_VOID
>>>      setpgrp();
>>> #else
>>>      setpgrp(getpid(), getpid());
>>> #endif
>>> 
>>> Why is it doing that? Is it simply what Apple is doing?
>>> I am trying to call $EDITOR (normally a TTY process) in my program which 
>>> has no gui either. 
>>> However I suspect the setpgrp mess up the terminal setting so the EDITOR 
>>> does not have the tty. I can tcsetpgrp from my process but then my process 
>>> is stopped. Can we do this:
>>> 0, just don't setpgrp, or
>>> 1, don't setpgrp if the parent's stdin is a tty and not setting the child's 
>>> stdin, or
>>> 2, add an option not to setpgrp. (it is an additional API though)
>>> I think 1 is the safest route and I can easily make a patch. I can do 
>>> either 0 or 1 if that's what people want.
>>> 
>> Moving to the dev list. 
>> Derek
>> 
> Here is a simple patch. It just don't setpgrp if the process is on a tty. 

Actually, the patch effects the task's process group setting if the *parent* 
task is on a tty.  Probably not what was intended.

> The current behavior does not make sense; if the child try to read/write 
> anything on the tty it will be stopped; and I don't think that's what 
> people want. If the goal is to prevent the child from messing with the 
> tty one can and should redirect stdin/stdout/stderr of the child.
> 
> Furthermore, I think process group only has something to do with the tty
> usage and the signal handling resulting from that, so ideally you do not 
> need to call setpgrp unless you are writing a shell or something; it 
> is pretty much a no-op in a GUI app or in Windows. Anyway I believe this 
> patch is safe and does what I want. 

Looking at the code, the intention of calling setpgrp is clearly to do two 
things ...

1. detach the task from any controlling terminal (there's a comment to say this 
is what's intended)
2. permit the -interrupt, -terminate, -suspend and -resume methods to control 
any subtasks (without it, the current code for these methods is wrong).

If setpgrp is not called, then the implementation of the other methods for 
controlling the task must also be changed.

However, while the intention of the existing code is fairly clear, it's not 
obvious that it's correct... it may well be that the current behavior is NOT 
what OSX does.
What we need is a set of a few simple test programs which we can include in the 
testsuite and run on OSX (and with gnuste on gnu/linux and bsd and mswindows) 
to make sure that we actually have consistent and OSX compatible behavior.

I would not like to change/break existing behaviors until/unless we know that 
the change is OSX compatible.