Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!sunkisd!uunet!munnari!otc!softway!necisa!boyd
From: boyd@necisa.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.wizards
Subject: Re: Process Group ID's (was: Re: pid rollover?)
Message-ID: <769@necisa.necisa.oz>
Date: 12 Feb 89 23:28:18 GMT
References: <460@oglvee.UUCP> <1800007@spdyne> <923@auspex.UUCP> <12118@rpp386.Dallas.TX.US> <763@necisa.necisa.oz> <12400@rpp386.Dallas.TX.US>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 30
Reply-To:

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