David Laight wrote:
> 1) loop forever with interrupts disabled hoping one will appear [1]
> 2) error the fork()

Yeah, error the fork with EAGAIN.

> 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
> are required.

I think bumping PID_MAX to 32767 should be fine.  So far as PID_MAX
stays <= SHRT_MAX, there would be no new issues to worry about.

> > 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.

There is still check for PID_MAX in procfs_vnops.c which needs
to be removed.

Please fix the new pid allocation code to honour PID_MAX and never
allocate pid higher than that - fail the fork if pid <= PID_MAX
wouldn't be available.

It would be also very good if you'd put thorough description of
the algorithm into the sources as comment, so that other people
would have less work discovering how the stuff works, and eventually
fix things in case of any problem.

I noticed that the generated PIDs are not completely sequential,
some are skipped and used later. Is it because of the pids being
kept idle for stale pud detection? Perhaps that code should only
be active with #ifdef DEBUG.

Jaromir 
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-