[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why does NSTask setpgrp on sub processes?
From: |
Derek Zhou |
Subject: |
Re: why does NSTask setpgrp on sub processes? |
Date: |
Wed, 20 Jan 2010 01:25:51 -0800 |
User-agent: |
KMail/1.12.4 (Linux/2.6.31; KDE/4.3.4; i686; ; ) |
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:
- Re: why does NSTask setpgrp on sub processes?, Derek Zhou, 2010/01/20
- Re: why does NSTask setpgrp on sub processes?, Richard Frith-Macdonald, 2010/01/20
- Re: why does NSTask setpgrp on sub processes?, Derek Zhou, 2010/01/20
- Re: why does NSTask setpgrp on sub processes?, Richard Frith-Macdonald, 2010/01/20
- Re: why does NSTask setpgrp on sub processes?, Derek Zhou, 2010/01/20
- Re: why does NSTask setpgrp on sub processes?, Derek Fawcus, 2010/01/20