Pids

[Chris Torek]

In article <266 at brl-smoke.ARPA> rbj at icst-cmr.arpa (root) writes:
>I just finished reading McKusick's paper on `Measuring & Improving
>the Performance of 4.2'. [...]
>
>1) Pids seem to wrap at 32K. 

Actually, at 30000.

>2) I have only observed this once, as our machine usually finds
>   an excuse to crash, or we reboot it for somne reason. Even so, it
>   took more than a week.

You just are not doing enough with your machine :-).  Ours tend to
wrap around every few hours or days.

>3) Until the wrap around, *each pid generated (++pid) is guaranteed
>   to be unique*!
>4) My solution is to have a flag (pidwrap) which is set at the obvious time.
>   If the flag is clear, *why search at all*? If not, do it the hard way.

This is not necessary.  4.3 has a `pidchecked' variable that it
sets to the top of a free range of pids starting at `mpid'.  This
means that one search at boot time sets this to 30000, after which
there are no scans until the first wrap.  It then starts mpid at
100 (not 1, since there are usually all sorts of servers cluttering
up the lowest part of the PID space) and does another scan.  This
usually nets a few hundred free PIDs at the least, and continues
working through any number of wraps.  It depends on only two things:
Process ID space is sparsely populated, and long-lived processes
are rare.

>5) Any reason not to use unsigned pids, this doubling their range?

Fear of breaking old code, perhaps.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu