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