Re: why does NSTask setpgrp on sub processes?

[Derek Zhou]

On Wednesday 20 January 2010 01:25:51 am 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. 
> > 
> > > 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.
> 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. 
> But the following program should illustrate the problem:
> 
> 
Oops, hit send too soon.

#import <Foundation/Foundation.h>

int main(int argc, char** argv)
{
  NSTask* editor = [NSTask new];
  [editor setLaunchPath: @"vi"];
  [editor launch];
  [editor waitUntilExit];
  NSLog(@"finished\n");
}

with the setpgrp (current behavior) it will hang because vi cannot get hold of 
the tty. 
without the patch which basically disable setpgrp vi will show and after you 
close vi
this program will exit.
I can add tcsetpgrp after the launch so vi can get hold of the tty but then 
after vi 
exit tty control is not back to my prog but the shell. I have to fg or send 
SIGCONT
to continue my prog.
I see what you mean, currently it is trying to send signal to the new group. 
But how many cases you really want to do that instead of just sending to the 
single 
process? Also by default if parent got killed all children got killed (SIGHUP? 
I 
am not sure) so the behavior is still roughly unchanged.     

Derek