In article <200412270013.TAA15297@Sparkle.Rodents.Montreal.QC.CA>,
der Mouse <mouse@Rodents.Montreal.QC.CA> wrote:
>>> 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 knows that *process* C is gone.  It doesn't know whether *pgrp* C is
>gone or not.  If C forked descendants (which are now orphans), pgrp C
>will still be around, and will be the correct one to put process D into
>(so that C's now-orphaned children are on the tty when that job has
>it).  But if pgrp C died with process C and has since been recreated by
>someone else, it is the wrong pgrp for D.  And I can't see any way for
>B to tell the difference - at least not when the process that recreated
>pgrp C is in the same session.
>
>> The situation is really more interesting when the shell forks a
>> pipeline, but this is not the situation here.
>
>Oh, there may be other processes in the pgrp, but that's not very
>relevant.  If any of them are still alive (or dead but unreaped), the
>pgrp is still around, and B knows it.

Well, you usually don't end up in a situation where you want to put
a process in an existing process group. For example when you fork
a pipeline, you can make the last process in the pipeline be the
parent of all other processes. If you do that, then this process
will still be around after after the other processes in the pipeline
have been reaped. Even if you killed that process so that it died
before the processes in the previous pipeline stages did, you really
don't need to put those processes in the proper process group...

christos