Re: Remote pid with SOCK_DGRAM local socket

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, May 15, 2011 at 12:07:00AM +0100, David Laight wrote:
 > > ...for ever-decreasing values of "not immediately". It doesn't take
 > > that long to cycle through 32768 processes any more, and I think we're
 > > pretty soon going to have to take the plunge and go to 32-bit pids.
 > 
 > They are kept low because some emulations (which might just have
 > been killed) can only handle 16bit pids, and to reduce typing
 > when kiling processes (and probably for layout in ps and top).
 > 
 > If the system has a lot of active processes, then the pid numbers
 > will increase.

bleh, emulations. That might require a two-tiered allocator, which
would be a big pain. The rest is only a hassle, but a fairly large one
(hence "take the plunge") ... but it's the cycle rate that's the big
concern.

 > Might be worth allowing 24bits, I think this will increase the
 > number of forks before a pid can by reused by a factor of 256.
 > (Can't remember off hand what the minimum is at the moment.)

It's close enough.

I wonder if it's feasible to take other steps to mitigate the effect
of cycling through.

 > Linux systems still allocated 'next free pid' - so it is fairly easy
 > to guess the next number.

I'm not sure that's still true, but even if so it doesn't matter. The
openbsd claim that it does is based on the assumption that there's a
lot of code in the wild that calls srandom(getpid()) and expects good
results, and that's just not been my experience.

-- 
David A. Holland
dholland%netbsd.org@localhost