Re: PID sequences

Alan Cox (
Tue, 24 Feb 1998 09:01:58 +0000 (GMT)

> > I did consider this issue when I was optimizing and making SMP safe
> > the current PID allocation scheme. If the above you say is true,
> > there is a fantastically efficient way we can allocate PIDs, and an
> > entire SMP lock in fork.c is removed.
> I have a concern. Whether or not this is valid is for you folks to
> decide. Read the theory that describes apache 1.3's mod_unique_id
> <>. Essentially I make
> an assumption that pid reuse is unlikely to occur within a single second.
> I'm sure I'm not the only one making this assumption (think Message-ID
> generation, tmp filename generation, yadda).
> If you can do this with 15-bit "random" pids that's great. Otherwise
> maybe pids have to go 31-bits. I didn't look at your scheme closely, but
> it didn't seem to be "random".

For the fast SMP pid case that would still be true (Im assuming here Dave
is thinking count[cpuid]<<4|cpuid or similar) ? For a "random" PID space
using a function that takes a key value and a counter input and produces
a 1:1 relationship keeps the same reuse properties but you never know what
pid is going to appear next.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to