Re: [PATCH] sigwait eats blocked default-ignore signals

[Roland McGrath <roland@redhat.com>]

> But I suspect we have other issues here. Let's suppose we have threads T1
> (main) and T2. T2 blocks SIGCHLD and does sigwait(SIGCHLD).
> 
> Now, we send SIGCHLD to the thread group. The signal is lost again because
> sig_ignored() returns true on T1's side.
> 
> Is this OK? [...]

Yes, it's OK if T1 has SIGCHLD unblocked.  When there are multiple threads
that either don't block the signal or are in sigwait for it, then it can go
to any of them and there are no guarantees at all about which.  So we
simply say that the signal went to the thread not in sigwait that has that
signal unblocked (T1).  When it got there, it was ignored.  The user
semantics are equivalent even if that thread never actually woke and
dequeued the signal to ignore it.

> I think __group_send_sig_info() shouldn't use sig_ignored() at
> all. Instead, we should split __group_complete_signal() into 2
> functions. The first one, say, choose_target() shoud be used instead. The
> second one, handle_fatal_signal() can also be used by tkill() and
> friends.

I will probably like any reorganization of the code that makes it cleaner.
But we don't need to change the behavior in this regard.  The most common
path is __group_send_sig_info (from sys_kill), so it would be a shame to
remove the short-circuit optimization there.  In fact, it is probably wrong
semantics to do so (for what applications expect, and possibly for POSIX
conformance).  That is, an unblocked, ignored (or default-ignore) signal
should not set TIF_SIGPENDING and interrupt a system call in progress or
just about to start.  Obviously this is not a huge problem, since that's
what happens under any debugger.  But still, an undesireable change of
semantics as well as de-optimization, I'd say.


Thanks,
Roland