In article <200412262032.PAA13732@Sparkle.Rodents.Montreal.QC.CA>,
der Mouse <mouse@Rodents.Montreal.QC.CA> wrote:
>>> It is admittedly _unlikely_ that all the old processes will die and
>>> some other process in the same session will recreate the process
>>> group, without my having noticed that all the old processes have
>>> died and thus realizing that the process group is gone.  But
>>> "unlikely" really isn't good enough.
>> In this particular case, it is good enough.  From the manual page for
>> setpgid:
>
>>      If the invoker is not the super-user, then the affected process
>>      must have the same effective user-id as the invoker or be a
>>      descendant of the invoking process.
>
>Yes, the *affected* process.  But the affected process is always an
>inferior of my shell.
>
>My example looks like this:
>
> - session leader
>    - some other process, pid A, pgrp A
>    - my new shell, pid B, pgrp B
>
>Now, my shell, B, forks process C.  As the first process of a new job,
>its PID gets used for the pgrp for the job, so it gets pgrp C.
>
>This process runs for a while, then dies.  My shell reaps the zombie,
>forks again, and gets PID D.  Now, I have a problem.
>
>If process C forked a child which is still around, pgrp C is still
>around, and C is the right pgrp to put D into.  But if C's pgrp died
>with it, then it's possible that, after I reaped C's zombie, A forked,
>got PID C, and has recreated pgrp C - and C is then the wrong pgrp for
>me to use for D.  But in either case, an attempt to put D into pgrp C
>will succeed.  I can't see any way for B to tell which case obtains.

The "after I reaped" is really "after B reaped", so "B" knows that "C"
is gone. It can then choose to the process group of "D" to "D". The
situation is really more interesting when the shell forks a pipeline,
but this is not the situation here.

christos