On Tue, Mar 28, 2000 at 11:41:19AM -0800, Ulrich Drepper wrote:
> yodaiken@fsmlabs.com writes:
>
> > So the nonmanager threads do
> > sigaction(n,s)
> > === save local copy of s,n,thread_id
> > real_sigaction(realprocessid(myid));
> > if unblocked a signal that is user_space pending
> > kill self with that signal
> >
> > Now the information about who blocks what is available in user space
> >
> > kill(gettpid(),n) where gettpid has been fixed to get the
> > root pid
> > === find someone who is not blocking and
> > kill(someone,n)
> > if all threads block, then mark signal
> > as pending
>
> You are completely neglecting that the signals are not coming alone:
>
> - there is a signal context. If the process which receives the signal
> first (mainly the manager) simply returns the signal context on its
> stack is lost.
Perhaps I'm missing something, but my idea was that the manager would
not be sent any signals by other threads.
> Copying it means garbage collection of some kind
I think you've misunderstood my idea. The data that is copied is
simply the information about what threads are announcing an intetion
to accept what signals.
> - you have to handle certain signal special (segfault, stop/continue).
> Especially the later contains the possibility for arbitrary many
> races if not done in the kernel.
But the POSIX standard permits such races -- no?
> - RT signals have to transport data which, again, can be in the signal stack.
>
> - sigaltstack must continue to work
Right. All that is taken care of. The mechanism just makes sure that
the actual kill or sigqueue call is directed to a thread (process) that
is willing to accept the signal. The race potential is only when
thread A is concurrently blocking signal N while thread B is trying to
send it and selected A as the destination. But that seems solvable.
>
>
> I'm cutting it short here.
>
> --
> ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
> Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
> Red Hat `--' drepper at redhat.com `------------------------
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:22 EST