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.019 / U:29.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site