[lkml]   [1996]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: proc fs and shared pids
    From: Linus Torvalds <>
    > 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.022 / U:10.592 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site