Xref: utzoo comp.unix.wizards:14633 comp.unix.xenix:4913
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!killer!texbell!uhnix1!sugar!ficc!walker
From: walker@ficc.uu.net (Walker Mangum)
Newsgroups: comp.unix.wizards,comp.unix.xenix
Subject: Re: pid rollover?
Summary: there's an easier way....
Message-ID: <3059@ficc.uu.net>
Date: 10 Feb 89 13:56:01 GMT
References: <460@oglvee.UUCP> <1989Jan31.164710.19502@ateng.ateng.com> <697@root44.co.uk>
Organization: Adytum, Inc.
Lines: 25

In article <697@root44.co.uk>, aegl@root.co.uk (Tony Luck) writes:
> 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
> 

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!

-- 
Walker Mangum                                  |  Adytum, Incorporated
phone: (713) 333-1509                          |  1100 NASA Road One  
UUCP:  uunet!ficc!walker  (walker@ficc.uu.net) |  Houston, TX  77058
Disclaimer: $#!+ HAPPENS