Messages in this thread |  | | From | Albert Cahalan <> | Subject | Re: proc fs and shared pids | Date | Thu, 1 Aug 1996 23:06:46 -0400 (EDT) |
| |
From: Linus Torvalds <torvalds@cs.helsinki.fi> > On Mon, 29 Jul 1996, Michiel Boland wrote: >> >> How is the proc FS going to handle tasks that share the same PID? > > Badly. > > Linus > > (Seriously, the CLONE_PID option needs to be cleaned up a bit, and I > suspect I'll make a 16-bit "thread ID" in the high bits of the pid or > something like that)
Great. Could thread ID 0 mean "all threads at once" and the individual threads are numbered starting from 1? That would let me kill -9 the whole group at once or just one thread at a time.
If someone wants to crash a Linux system, I know where they should poke it... I'm not so sure CLONE_PID is a good idea for 2.0.xx.
While fixing /proc, we might as well take the oportunity to reorganize. All the /proc/pid stuff can remain static until Linux 3.1 or so, while new stuff can go in /proc/proc/pid/tid. (hex please!) I'd like to migrate to something sane that doesn't mix the pid directories in with the net, scsi, and other stuff.
Is a 16-bit pid enough? I could imagine wanting some extra bits to specify what processor node so that it would be easy to find the process in a Linux supercomputer. (if process migrates, drop the bits and search all nodes) I could also imagine running out of pids - BTW, does the kernel check for that or just get stuck? There are only around 30000 pids, and some systems have that many processors already.
|  |