FAQ

Torvalds on POSIX threads

Joshua N Pritikin
Apr 10, 2000 at 9:06 pm
A bit later, Linus Torvalds made a case about PID sharing and gave some
example code. He went on to say, about threading:

Note that the reason the kernel is not POSIX-compliant is:

o the POSIX standard is technically stupid. It's much better to use a
cleaner fundamental threading model and build on top of that.
o things like the above are just so much better and more easily done in
user space anyway.

The reason LinuxThreads has a hard time becoming POSIX-compliant is that
I refuse to apply stupid patches, and a lot of the patches sent to me
have been frankly stupid. They've often implemented pthreads
functionality without any actual thought of how it _could_ be done more
cleanly with a user/kernel split.

...

http://kt.linuxcare.com/kt20000410_62_print.epl

--
"May the best description of competition prevail."
via, but not speaking for Deutsche Bank
reply

Search Discussions

7 responses

  • Chip Salzenberg at Apr 10, 2000 at 9:25 pm

    According to Joshua Pritikin:
    o the POSIX standard is technically stupid. It's much better to use a
    cleaner fundamental threading model and build on top of that.
    o things like the above are just so much better and more easily done in
    user space anyway.
    I agree. POSIX threads' signal-handling model is really awkward, if I
    understand it correctly. I've never spent a lot of time on it, but
    wearing my implementor hat, just the very idea of having a separate
    signal mask for each thread gives me the screaming heebie jeebies.

    I suspect that Topaz's threading will be built on our own
    abstractions, possibly borrowed from the Mozilla code (as Linus
    himself suggested). But that's a ways down the pike.
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • Dan Sugalski at Apr 10, 2000 at 9:33 pm

    At 02:25 PM 4/10/00 -0700, Chip Salzenberg wrote:
    According to Joshua Pritikin:
    o the POSIX standard is technically stupid. It's much better to use a
    cleaner fundamental threading model and build on top of that.
    o things like the above are just so much better and more easily done in
    user space anyway.
    I agree. POSIX threads' signal-handling model is really awkward, if I
    understand it correctly. I've never spent a lot of time on it, but
    wearing my implementor hat, just the very idea of having a separate
    signal mask for each thread gives me the screaming heebie jeebies.
    Signals are pretty broken under threads, that's for sure. Their limitations
    really come to the forefront with threads. The lack of guarantees built
    into the standard doesn't help much either.

    The only sane way to handle signals with threads is to mask them off for
    all your threads except one that's set up to handle them. (The various OS
    vendors don't even agree on which signals are synchronous and which are
    async under threads just to add to the fun)

    Dan

    --------------------------------------"it's like this"-------------------
    Dan Sugalski even samurai
    dan@sidhe.org have teddy bears and even
    teddy bears get drunk
  • Jarkko Hietaniemi at Apr 10, 2000 at 10:55 pm
    Somewhat tangential but still related:

    http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-04/msg00418.html

    --
    $jhi++; # http://www.iki.fi/jhi/
    # There is this special biologist word we use for 'stable'.
    # It is 'dead'. -- Jack Cohen
  • Gurusamy Sarathy at Apr 14, 2000 at 11:24 pm

    On Mon, 10 Apr 2000 17:31:35 EDT, Dan Sugalski wrote:
    The only sane way to handle signals with threads is to mask them off for
    all your threads except one that's set up to handle them.
    That's just one half of the problem. We still need a first-class event
    abstraction. Can anyone kindly summarize the status of the event-loop
    module(s) for me? Thanks in advance.


    Sarathy
    gsar@ActiveState.com
  • Chaim Frenkel at Apr 10, 2000 at 10:31 pm
    "CS" == Chip Salzenberg writes:
    CS> I agree. POSIX threads' signal-handling model is really awkward, if I
    CS> understand it correctly. I've never spent a lot of time on it, but
    CS> wearing my implementor hat, just the very idea of having a separate
    CS> signal mask for each thread gives me the screaming heebie jeebies.

    <stupid question>

    Why should a signal mask per_THREAD, be any harder than a signal mask
    per_PROCESS?

    </stupid question>

    I recall having this under good ol' MVS. Each process/task within each
    address space had it's own set of capablities.

    Hmm, unless the problem is the poor split between address spaces and
    processes/tasks under unix?

    <chaim>

    <old professor>
    Now there was some raw threading. None of this posix mush. Lock and Set,
    Spin Locks, bare metal. Oh, those were the days....
    </old professor>

    --
    Chaim Frenkel Nonlinear Knowledge, Inc.
    chaimf@pobox.com +1-718-236-0183
  • Chip Salzenberg at Apr 10, 2000 at 11:01 pm

    According to Chaim Frenkel:
    <stupid question>
    Why should a signal mask per_THREAD, be any harder than a signal mask
    per_PROCESS?
    </stupid question>
    Because POSIX threads are _supposed_ to be implementable on top of a
    UNIX system that doesn't have kernel threads. And that means that a
    robust implementation has do do a lot of user-mode processing on each
    signal delivery, *or* has to make at least one and maybe more system
    calls on every user-mode-thread context switch.

    On a system like Linux with kernel threads, that part isn't _so_ bad.
    But there's still an unholy mess surrounding the semantics of signal
    delivery; a group of threads is in some ways a bunch of separate
    processes, but in some ways is still supposed to act like one process.

    Linux's clean separation of process semantics into flags for the
    clone() call is really a great step toward sanity.
    I recall having this under good ol' MVS. Each process/task within
    each address space had it's own set of capablities.
    That, in itself, is no big deal.
    <old professor>
    Now there was some raw threading. None of this posix mush. Lock and Set,
    Spin Locks, bare metal. Oh, those were the days....
    </old professor>
    <old hacker>
    Lock and set? Luxury! When I started with threading, we had to flush
    the cache manually with a dummy jump...
    </old hacker>

    PS: Whether this is true or not is left as an exercise for the reader.
    --
    Chip Salzenberg - a.k.a. - <chip@valinux.com>
    "I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early." // MST3K
  • Dan Sugalski at Apr 10, 2000 at 9:26 pm

    At 05:06 PM 4/10/00 -0400, Joshua N Pritikin wrote:
    o the POSIX standard is technically stupid. It's much better to use a
    cleaner fundamental threading model and build on top of that.
    It's a technical compromise and isn't perfect. This is supposed to be a
    surprise? There's not a cross-platform standard out there that doesn't suck
    in one form or fashion. The Linux implementation does exacerbate the
    problems, though it wouldn't surprise me if that was intentional.

    It'd be nice if they took the damn POSIX Pthreads label off the things--if
    they aren't abiding by the standard they shouldn't use the name.

    Dan

    --------------------------------------"it's like this"-------------------
    Dan Sugalski even samurai
    dan@sidhe.org have teddy bears and even
    teddy bears get drunk

Related Discussions