lkml.org 
[lkml]   [2000]   [Aug]   [25]   [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 native Linux"
    yodaiken@fsmlabs.com wrote:
    > > pthread_trust_me(RAW_SIGNALS_PLEASE);
    > > for (;;); /* hee hee */
    >
    > This is not a tough one:
    >
    > pthread_raw_signals
    > This call shifts delivered signal numbers up so that
    > "special" POSIX signals can be delivered to a process. Sending signal N to
    > a thread that has executed this call causes the kernel to deliver
    > signal N+SIG_RAWSHIFT. So kill(pid,SIG_KILL-SIG_RAWSHIFT) is needed
    > to hammer such a process.

    I'm seriously starting to think that a "sys_do_pthread_cruft()" is the
    sanest way out of this mess... i.e. a kernel syscall that would handle
    the singal redistribution - the "master" pthread process would do this
    and nothing else.

    Yes, I know it's god-awful horrible to codify anything from pthreads in
    the kernel, but:
    * These suggestions of having special-purpose signals that have special
    meaning depending on a special-case flag, are really just as crufty.
    You're adding grossness in (a few places in) the kernel to handle a
    pthread-specific case. I don't think any other threading model is
    going to want this facility (based on the fact that non-pthreads people
    haven't exactly been clamoring for it). So no matter what correctly
    resolving this issue is going to require pthread-cruft in the kernel. We
    might as well do it in a straighforward way.

    * If you have userspace redistribute signals from the master thread,
    how are you going to fudge things like siginfo.pid? I suppose you
    could pass the real siginfo_t across the shared VM and somehow
    trick glibc into using that instead of what the slave child would
    get from the kernel, but ew...

    * The kernel can trivially handle the security issues (i.e. making sure
    SIGKILL/SIGSTOP get delivered), keeping expected semantics.

    * It would be hard for userspace to do potential optomizations like
    "thread #4 has this signal unblocked and it ran recently on this
    CPU... so its thread-private data is probably in CPU cache so I'll
    give this signal to it instad of thread #3". I'm not sure if this
    is useful, but the kernel could be made to do it.

    I envision something like "sys_pause()", except: (1) in a loop, and (2)
    it would take the signal and munge the things necesary to deliver it
    to a chosen process. Of course it would need to exit at some point,
    probably when the last slave member of its thread group dies (then the
    syscall would return a status, like sys_wait() probably). Shouldn't
    be a WHOLE lot of code.

    <braces for flames>

    -Mitch
    -
    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:2.793 / U:0.312 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site