Messages in this thread | | | Date | Thu, 24 Aug 2000 11:40:59 -0600 | From | yodaiken@fsmlabs ... | Subject | Re: SCO: "thread creation is about a thousand times faster than on native Linux" |
| |
On Thu, Aug 24, 2000 at 07:42:43PM +0200, Andi Kleen wrote: > On Thu, Aug 24, 2000 at 09:23:34AM -0700, Linus Torvalds wrote: > > Note that the "first thread that doesn't block it" decision is the really > > nasty one. If all threads have it blocked, we need to have it pending. But > > we can only have it pending for _one_ thread. I think POSIX allows this, > > but I'm not sure.
POSIX states "the choice of threads is left entirely up to the implementation .. to give implementations the freedom to deliver the signal to the "easiest possible" ... "
Delivery of pended signals is another thing that can be solved by the root thread daemon. The original signal is delivered to the root thread. This thread determines that nobody wants it, and marks it pending. We've fixed libc so that the real threads that change their masks must go via a user space routine that simulates the signal all in user space when it gets unblocked.
(POSIX seems to always provide some wriggle room to do the right thing or at least force the costs to be paid by the offending program).
> > I _really_ really want to avoid this. I think POSIX is vague on the > > requirement, and quite frankly, a shared sigprocmask() is a horror. It > > really doesn't fit in, at all.
POSIX is not vague. It is quite clear that implementations may core dump programs that try this.
> I think shared sigprocmask is very useful. How otherwise would you lock > against signals in a multithreaded process ? Locking is really > needed when you're e.g. using queued SIGIO for IO. Doing the locking > in user space is really nasty in this case
lock_signals = 1; // all signal functions in my code check this // and do the appropriate thing.
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com
- 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/
| |