lkml.org 
[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: SCO: "thread creation is about a thousand times faster than on
       From: Linus Torvalds <torvalds@transmeta.com>
    Date: 2000-08-24 16:23:34

    On Thu, 24 Aug 2000, Andi Kleen wrote:
    > For good behaviour you need a shared sigprocmask(). (I just ran
    > into a situation where shared signal blocking would have been
    > very useful on Linux). You basically want to protect your data
    > structures that could be accessed by signals against signals send
    > to any thread, otherwise sigprocmask are pretty useless.

    I _really_ really want to avoid this. I think POSIX is vague on the
    requirement, and quite frankly, a shared sigprocmask() is a horror. It
    really doesn't fit in, at all.

    POSIX says that the behaviour of sigprocmask() is unspecified for
    multi-threaded processes, so there's nothing wrong with leaving
    sigprocmask() as it is.

    Basically, we can add thread groups with about 10 lines worth of diffs,
    and they will be "obviously correct". That means that if this helps
    LinuxThreads, it can happen before 2.4.0-final.

    I don't think thread groups alone will help LinuxThreads right now.
    Not without the proposed changes to the signal handling.

    In contrast, a shared sigprocmask() simply isn't going to happen. That is
    a 2.5.x issue, and even in 2.5.x I'd really like to avoid it, because it
    would be a design mistake, I suspect.

    I think even POSIX recognizes that :-).

    > [Earlier there were proposals to add a CLONE_WAITPID for that, but I think
    > controlling it via the tid and prctl would be more elegant and flexible]

    I'd prefer CLONE_WAITPID, I think.

    Is CLONE_WAITPID really necessary if we have CLONE_PARENT available?
    Using CLONE_PARENT one can just make the initial thread the parent of
    all other threads, and keep the initial thread around even after it
    calls pthread_exit(). I don't think that's terribly hard to implement.

    Mark
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:0.059 / U:0.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site