Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!killer!rpp386!jfh
From: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Process Group ID's (was: Re: pid rollover?)
Summary: what really happens when a process exits?
Message-ID: <12400@rpp386.Dallas.TX.US>
Date: 8 Feb 89 06:58:59 GMT
References: <460@oglvee.UUCP> <1800007@spdyne> <923@auspex.UUCP> <12118@rpp386.Dallas.TX.US> <763@necisa.necisa.oz>
Reply-To: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Organization: River Parishes Programming, Dallas TX
Lines: 31

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