[lkml]   [2000]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SCO: "thread creation is about a thousand times faster than on native Linux" 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

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