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

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B