Xref: utzoo comp.unix.wizards:14663 comp.unix.xenix:4938
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!nosc!ncr-sd!greg
From: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel)
Newsgroups: comp.unix.wizards,comp.unix.xenix
Subject: Re: pid rollover?
Message-ID: <880@ncr-sd.SanDiego.NCR.COM>
Date: 13 Feb 89 09:44:55 GMT
References: <460@oglvee.UUCP> <1989Jan31.164710.19502@ateng.ateng.com> <3059@ficc.uu.net> <11212@ulysses.homer.nj.att.com>
Organization: NCR Corporation, Rancho Bernardo
Lines: 25

In article <11212@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com
(Steven M. Bellovin) writes:
>Many years ago, I saw a mod to a V6 UNIX(r) system that used the process
>table slot as the low-order 8 bits of the pid, and incremented a counter
>in the high-order bits to ensure that a pid wasn't reused too soon.

I confess -- I did it.  It seemed to me that the computer would be wasting
a lot of time looking through the process table to see if a PID was already
in use, so I dreamed up the hack of using the low-order bits as the table
index to avoid the search.  It was OK on a PDP-11/40, but on a PDP-11/70
we were approaching the maximum number of processes, and the process
numbers themselves were cycling too fast -- if processes were being created
and dying rapidly, the same process slot tended to be reused, so after 128
tries, the same PID came up again.  Replacing the free-process stack with
a queue so that different process slots were being used simply put back in
the overhead that removing the search had taken out.

But the real killer was that I could never measure any performance improvement
and the code required was bigger.  Since space was always tight (you youngsters
haven't lived until you've shoehorned a full networking kernel into 49,152
bytes) I eventually took it out.

(MO, would this be another Greg Noel Hack?)
-- 
-- Greg Noel, NCR Rancho Bernardo   Greg.Noel@SanDiego.NCR.COM  or  greg@ncr-sd