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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:15 EST