Re: why does NSTask setpgrp on sub processes?

[Richard Frith-Macdonald]

On 20 Jan 2010, at 09:25, Derek Zhou wrote:

> On Wednesday 20 January 2010 12:15:11 am Richard Frith-Macdonald wrote:
>> 
>> On 20 Jan 2010, at 07:21, Derek Zhou wrote:
>>> 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.
> That is what I want to do. If the parent is on a tty, then you either 
> 1, want the task to use the tty too; so you don't want to setpgrp and has it 
> stalled
> 2, do not want it to use the tty, then you should just redirect the 
> stdin/out/err
> I can modify the patch so it conditions on both the parent and the child on 
> tty but 
> it miss the cases that the child is opening /dev/tty directly. I think gpg 
> does 
> that to read the password. 

I don't think you can infer anything about what the behavior should be from 
whether the 'parent is on a tty'.

>>> 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.

I think the background process is stopped if it tries to *read*, not if it 
tries to write.
I also strongly suspect that this is the behavior expected by most people ... 
if background processes were freely able to read from the terminal then you 
would have a conflict between different processes trying to read data.

>>> 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.
> The only mac I have access do not have a compiler installed. And I don't know 
> how 
> to make an automatic test program since this involve tty and human 
> interaction. 

I added code to the testsuite to check this behavior see the last test in 
base/NSTask/launch.m and the Helpers/processgroup.m program).
Running this on OSX deonstrates that OSD *does* change the process group of 
processes launched from NSTask, so it looks like the current behavior is 
correct.

> But the following program should illustrate the problem:

I think you forgot to add it.