Messages in this thread | | | Date | Thu, 24 Aug 2000 23:01:56 -0700 | From | Mitchell Blank Jr <> | Subject | Re: 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/
| |