Xref: utzoo comp.unix.wizards:14598 comp.unix.xenix:4882 Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!stl!stc!root44!aegl From: aegl@root.co.uk (Tony Luck) Newsgroups: comp.unix.wizards,comp.unix.xenix Subject: Re: pid rollover? Message-ID: <697@root44.co.uk> Date: 8 Feb 89 12:31:37 GMT References: <460@oglvee.UUCP> <1989Jan31.164710.19502@ateng.ateng.com> <8857@alice.UUCP> Reply-To: aegl@root44.UUCP (Tony Luck) Organization: UniSoft Ltd, London, England Lines: 30 In article <8857@alice.UUCP> debra@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