lkml.org 
[lkml]   [1996]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: proc fs and shared pids
Date
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.




\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.036 / U:0.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site