pid rollover?
Tony Luck
aegl at root.co.uk
Wed Feb 8 22:31:37 AEST 1989
In article <8857 at alice.UUCP> debra at alice.UUCP () writes:
>This is not the reason at all. The limit on pid's is 30000, which is just
>an arbitrary number, for historical reasons, and which appears to be the
>same on all Unix systems (at least all I've seen). It probably is smaller than
>32767 because Unix originally ran on 16-bit machines (PDP), but the number
>is just arbitrary. Any number greater than the maximal number of processes
>would do. ^^^^^^^
Why "greater"? If you reduce the range of pids enough, eventually you
get to the state where the number of possible pids is equal to the
number of slots in the proc table, and thus you could do away with the
few places that still search the proc table for pids by just defining
the pid to be the index into the proc table. (and WOW, you could save
2 bytes from the proc structure by not having a p_pid element at all!).
What would break if you did this (do the big mainframes already do
something like this anyway ... if you want 1000 users on a machine you
must be able to cope with 10,000 active processes ... and 30,000 pids
would wrap round every few minutes anyway) ... it might be rather
disconcerting to run a script like:
while :
do
echo "" &
wait
done
and have the *same* pid printed for every echo (assuming an otherwise idle
system, and a proc table allocator that gave you the same slot every time)
But would anything actually break?
-Tony Luck <aegl at root.co.uk>
More information about the Comp.unix.xenix
mailing list