chip@ateng.ateng.com (Chip Salzenberg) (02/01/89)
According to jr@oglvee.UUCP (Jim Rosenberg): >Our system is an Altos 2000 running Xenix System V. The CPU is a 386, and >the C compiler produces 4 as sizeof(int). However we seem to be hitting >rollover of pids at 32K, implying that the kernel must be using short as the >type of a pid -- at least internally. The getpid() system call has to work for '286 binaries under Xenix/386. So all pids must be representable as a 16-bit integers. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
debra@alice.UUCP (Paul De Bra) (02/02/89)
In article <1989Jan31.164710.19502@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: }According to jr@oglvee.UUCP (Jim Rosenberg): }>Our system is an Altos 2000 running Xenix System V. The CPU is a 386, and }>the C compiler produces 4 as sizeof(int). However we seem to be hitting }>rollover of pids at 32K, implying that the kernel must be using short as the }>type of a pid -- at least internally. } }The getpid() system call has to work for '286 binaries under Xenix/386. }So all pids must be representable as a 16-bit integers. 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. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
aegl@root.co.uk (Tony Luck) (02/08/89)
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 <aegl@root.co.uk>
walker@ficc.uu.net (Walker Mangum) (02/10/89)
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
tif@cpe.UUCP (02/10/89)
Written 6:31 am Feb 8, 1989 by root44.UUCP!aegl in cpe:comp.unix.xenix >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 At the very least, HDB-style pid-locking would be less useful since a given PID is quite likely to have SOME process running. Paul Chamberlain Computer Product Engineering, Tandy Corp. {killer | texbell}!cpe!tif
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (02/13/89)
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.
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (02/13/89)
In article <11212@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes: >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. I confess -- I did it. It seemed to me that the computer would be wasting a lot of time looking through the process table to see if a PID was already in use, so I dreamed up the hack of using the low-order bits as the table index to avoid the search. It was OK on a PDP-11/40, but on a PDP-11/70 we were approaching the maximum number of processes, and the process numbers themselves were cycling too fast -- if processes were being created and dying rapidly, the same process slot tended to be reused, so after 128 tries, the same PID came up again. Replacing the free-process stack with a queue so that different process slots were being used simply put back in the overhead that removing the search had taken out. But the real killer was that I could never measure any performance improvement and the code required was bigger. Since space was always tight (you youngsters haven't lived until you've shoehorned a full networking kernel into 49,152 bytes) I eventually took it out. (MO, would this be another Greg Noel Hack?) -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd