Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amdahl!uunet!vsi!friedl
From: friedl@vsi.COM (Stephen J. Friedl)
Newsgroups: comp.unix.wizards
Subject: Re: pid rollover?
Message-ID: <1043@vsi.COM>
Date: 5 Feb 89 00:35:29 GMT
References: <460@oglvee.UUCP> <1800007@spdyne> <923@auspex.UUCP>
Organization: V-Systems, Inc. -- Santa Ana, CA
Lines: 28

> I believe that it sets nextpid to 100, at least it did on our BSD system.

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

Please note that PIDs are not necessarily monotonically
increasing on all systems.  On the AT&T 3B15 (the master CPU for
the multiprocessor 3B4000) the PIDs jump all over the place.  For
example, a trivial program to fork 20 times prints PIDs in the
following order:

12331 12331 8236 12331 8236 16397 12331 8236 16397 20535
12331 8236 16397 20535 28918 12331 8236 16397 20535 28918

Note the reassignment of old PIDs here.  You have to look
at the PIDs in hex to get any kind of pattern, and it probably
reflects processor assignment or some such.

     Steve

-- 
Stephen J. Friedl        3B2-kind-of-guy            friedl@vsi.com
V-Systems, Inc.       I speak for you only      attmail!vsi!friedl
Santa Ana, CA  USA       +1 714 545 6442    {backbones}!vsi!friedl
Nancy Reagan on these *stupid* .signatures: "Enough already, OK?"