Subject: Re: new pid allocation - any advantages?
From: David Laight <email@example.com>
Date: 04/05/2003 19:28:18
> I.e, if PID_MAX is 30000, can a PID > 30000 ever be allocated?
> If so, then this is not the correct behaviour IMHO.
I'll turn it the other way around.
If you cannot allocate a PID below PID_MAX should you:
1) loop forever with interrupts disabled hoping one will appear 
2) error the fork()
3) allocate a number above PID_MAX
> I can think of specific cases where a user does not want a new PID to
> exceed PID_MAX under any circumstance. E.g, for compatiblity with
> certain systems with 16 bit PIDs (PID_MAX =~ 32767), or where PIDs
> aren't to exceed 5 digits when printed (PID_MAX == 99999).
That can be guaranteed by ensuring that maxproc is less than ~4777 .
(I'd have to check the actual value)
Note that because the table is sized 2^n it is hard to stop pids
between 30001 and 32767 being allocated when more that 16383 pids
> Also, procfs checks that the requested pid doesn't exceed PID_MAX,
> so if your code doesn't enforce this limitation, you won't be able to
> access those via procfs. ("oops!")
That is a silly restriction in procfs, I thought I'd killed it.
 IIRC the old code could easily do that.
 Each process can require unique pid, pgid and sid, it isn't
16384/3 because about 2000 pids are kept idle to help detect
stale pud values.
David Laight: firstname.lastname@example.org