Re: SCO: "thread creation is about a thousand times faster than on native Linux"

From: Mitchell Blank Jr (
Date: Fri Aug 25 2000 - 01:01:56 EST 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 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>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:15 EST