Re: Signals and an exiting thread

On Fri, Oct 2, 2009 at 1:12 PM, Jilles Tjoelker <jilles_at_stack.nl> wrote:
 ---  snip ---
> SIGKILL cannot be masked. Is it possible that a kill(SIGKILL) is
> assigned to a dying thread and lost?
>
> (SIGSTOP cannot be masked either, but its processing is done by the
> sending thread, so it should be safe.)
>
> I suppose that race can also occur in other uses of pthread_sigmask().
> If a thread masks a signal for a while, and that signal is assigned to
> that thread just as it is executing pthread_sigmask(), it will only be
> processed when that thread unblocks or accepts it, even though other
> threads may have the signal unmasked or be in a sigwait() for it.
> Signals sent after pthread_sigmask() has changed the signal mask are
> likely processed sooner because they will be assigned to a different
> thread or left in the process queue.
>
> POSIX seems to say that signals generated for the process should remain
> queued for the process and should only be assigned to a thread at time
> of delivery.
>
> This could be implemented by leaving signals in the process queue or by
> tracking for each signal in the thread queue whether it was directed at
> the thread and moving the process signals back at sigmask/thr_exit.
> Either way I am not sure of all the consequences at this time.
>
> By the way, SA_PROC in kern_sig.c is bogus, because whether a signal is
> directed at a specific thread depends on how it was generated and not on
> the signal number. Fortunately, it is not used.
>
> --
> Jilles Tjoelker
>

Thanks for the helpful tips.  Andriy's suggestion to only handle
signals from a "sable" thread is a good one -- it would solve some
problems.

However, we did a little more investigation, and the SIGKILL example
Jilles posted happens as well.  We post a SIGKILL to a thread, and the
thread goes away before it can kill the process.  I like the idea of
keeping signals like SIGKILL on the process queue so that it will be
picked up with SOME thread.  The other way is basically what Kostik
suggested -- although I like the idea of copying the signal back to
the proc queue there as well ...

I'll play around with it and see what solves our problem, and I'll
post back here with what I find out.

-Justin