Xref: utzoo comp.unix.wizards:14657 comp.unix.xenix:4935
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!gatech!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.unix.wizards,comp.unix.xenix
Subject: Re: pid rollover?
Message-ID: <11212@ulysses.homer.nj.att.com>
Date: 13 Feb 89 00:45:51 GMT
References: <460@oglvee.UUCP> <1989Jan31.164710.19502@ateng.ateng.com> <3059@ficc.uu.net>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 12

In article <3059@ficc.uu.net>, walker@ficc.uu.net (Walker Mangum) writes:
} Actually, there's a much easier method (since the pid really is arbitrary).
} Many OS's for real-time type systems (where getting to a process's control
} info with efficiency is important) simply assign a "pid" (task id) that is
} the *index* into the "process table", or is actually an address in the 
} "process table".  A system that comes to mind is Modcomp's MAX 32 OS.  It
} ain't Unix, but it *can* process 50,000 *external* interrupts and do 10,000 
} process context switches per second!

Many years ago, I saw a mod to a V6 UNIX(r) system that used the process
table slot as the low-order 8 bits of the pid, and incremented a counter
in the high-order bits to ensure that a pid wasn't reused too soon.