Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!ll-xn!adelie!mirror!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.unix.wizards
Subject: Re: pid rollover?
Message-ID: <1399@X.UUCP>
Date: 3 Feb 89 07:16:00 GMT
References: <460@oglvee.UUCP> <1800007@spdyne> <923@auspex.UUCP> <12118@rpp386.Dallas.TX.US>
Organization: Servants of the Great White Frog
Lines: 20

In article <12118@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
> In article <923@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
> >And it doesn't on his (S5?) system.  Different systems do it
> >differently.  (Actually, the S5R3 code sets "nextpid" - actually, "mpid"
> >- to 0, but if process ID 0 isn't already in use something rather
> >strange has happened on your system....)
> The kernel repeatedly scans for a valid pid.  So the concern over
> conflicting pid's is unfounded.

It is possible, nay probable, that the reason someone had it cycle from 100
was that they noticed that on their system, enough of the low numbers were in
use by daemons that it wasted a lot of time finding the lowest unused one.
Though the cost per hour of uptime may be nearly negligible, the cost of
avoiding it IS negligible.
-- 
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu

Presumably this means that it is vital to get the wrong answers quickly.
		Kernighan and Plauger, The Elements of Programming Style