[comp.unix.wizards] Process Group ID's

jfh@rpp386.Dallas.TX.US (John F. Haugh II) (02/08/89)

In article <763@necisa.necisa.oz> boyd@necisa.necisa.oz (Boyd Roberts) writes:
>In article <12118@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
>>	for (pp = proc;pp < v.ve_proc;pp++)
>>		if (pp->p_stat && pp->p_pid == mpid)	/* oops, exists */
>>			goto again;
>
>Guess again, bozo.  You've also got to check for p->p_pgrp clashes.
>You can't have mpid == an active process group id.

I may be wrong - I checked using the `compile a program and see how it
behaves' school of UNIX behaviour determination - but you can't have an
active process group if the process group leader is dead.

Or did I miss something?
% crash
> proc 16
SLT ST  PID  PPID  PGRP   UID  EUID PRI CPU    EVENT NAME       FLAGS
 16 s  9378     1     0     0     0  39   0  6000000 hang       incore text

That was a member of a process group which was exited from.  The program
lingered because it was ignoring the SIGHUP it was sent.  As you can see,
the process group is now zero.

Before I spend too many more hours trying to figure out the circumstance
under which the process group would not be reset to zero, does anyone
know of one?
-- 
John F. Haugh II                        +--Quote of the Week:------------------
VoiceNet: (214) 250-3311   Data: -6272  | "Get it through your head:
InterNet: jfh@rpp386.Dallas.TX.US       |     CARS ARE THE ENEMY."
UucpNet : <backbone>!killer!rpp386!jfh  +------    -- Bob Fishell    ----------

boyd@necisa.necisa.oz (Boyd Roberts) (02/13/89)

In article <12400@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
>
>% crash
>> proc 16
>SLT ST  PID  PPID  PGRP   UID  EUID PRI CPU    EVENT NAME       FLAGS
> 16 s  9378     1     0     0     0  39   0  6000000 hang       incore text
>

Well, it looks like Sys V is _wrong_ again.  Once your process group
leader dies all living processes with that p_pgrp get it set to zero.
Great work!!

Just say I _don't_ want that to happen?  Just say I _do_ want to be able
to signal processes in my group regardless of the state of my process
group leader?  This is typical Sys V brain-damage.

From memory, V8 & 32V check for p_pgrp clashes and do _not_ zero p_pgrp
fields, in living processes, when their process group leader dies.

Just when you think the universe is relatively sane, Sys V _proves_ that
in no way is that the case.

How many more quasi-crucial interfaces will be stomped on in V.4?


Boyd Roberts			NEC Information Systems Australia

boyd@necisa.necisa.oz

``When the going gets wierd, the weird turn pro...''