lkml.org 
[lkml]   [1996]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: proc fs and shared pids


    On Sun, 4 Aug 1996, lilo wrote:
    > >
    > > 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.
    >
    > This does sound like a great way to please both those of us who are nervous
    > about not having unique pids, and those who insist on having them.
    >
    > If you ignore the existence of the 16-bit thread ID by zeroing it, you get a
    > kill which affects all of the threads.
    >
    > In fact, this sounds so good that there's got to be something technically
    > wrong with it.... :) :)

    There isn't. We discussed this some time ago (I don't remember with whom),
    and it was felt to be generally a "good thing". It has the advantage of
    allowing normal UNIX utilities to automatically work both on the whole
    "process" (in the traditional thread meaning) while still allowing the same
    utilities to handle individual threads if they wanted to.

    Traditional threads suck. The whole idea with the Linux "clone()" was to look
    at the thread idea from a new perspective, and have something that makes the
    difference between threads and processes fade away. We want to have threaded
    programs, but we ALSO want to not think of the threads as anything special:
    they are just another form of processes. As such I don't want special thread
    system calls, instead I want _generic_ system calls that work both in a
    thread and a process context. That's why I proposed the high-bits thread-ID
    approach.

    The only problem as far as I'm concerned is that I don't actually use the
    thread facilities, and as such I'm unlikely to start coding. I've been hoping
    that people that are interested in threads start using clone() for them
    (which finally has happened, thank God), and that as it becomes clear that we
    need more support (like the thread ID thing) people start sending me patches.
    Hint hint..

    Again, I'd like people not to look too closely at pthreads or other
    "traditional" threads packages. If people _do_ start playing around with the
    kernel for better thread support, please don't try to force any pthread
    specific system calls or anything like that. Think in more generic terms, and
    do any new system calls (if needed) in such a way that you can implement
    pthreads on top of them, but don't limit yourself to any specific interface.
    Try to make the system calls make sense even _outside_ a threaded
    environment.

    Linus


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