Re: [PATCH] sigchain: recover from concurrent double-pops of the same signal

[Phillip Wood <phillip.wood123@gmail.com>]

On 30/10/2026 08:45, Oswald Buddenhagen wrote:
> On Thu, Oct 29, 2026 at 04:03:18PM +0000, Phillip Wood wrote:
>> On 29/10/2026 14:15, ian4hu wrote:
>>> I left SIGPIPE out precisely to keep the "upstream of a pipe
>>> dies of SIGPIPE" behaviour that common-init.c restores.  The set I
>>> plan to block is SIGINT, SIGHUP, SIGTERM and SIGQUIT.  If you
>>> think SIGPIPE belongs in it too, I will add it.
>>
>> I think we want to block all signals when we create a thread, so that 
>> all signals are handled by the main (initial) thread.
>>
> that wording again does not address the fact that sigpipe is different 
> due to being thread-directed [1]. even if the outcome is identical, it 
> needs to be reasoned about separately.

Oh, thanks for pointing that out, I hadn't realized some signals were 
directed at a specific thread rather than the process. According to my 
copy of The Linux Programming interface SIGBUS, SIGFPE, SIGILL and 
SIGSEGV are all thread-directed as well so, to ensure the process is 
killed if we receive one of those signals, we shouldn't be blocking any 
of those either. sigchain_push_common() installs a handler for SIGPIPE 
so, in principle, we could end up unwinding the chain in two threads, 
I'm not sure if that is likely in practice. If that is an issue, maybe 
we could set a flag in the signal handler to indicate it has already run 
(though I'm not sure it is possible to do that race-free without 
something like atomic_flag_test_and_set()).

Thanks

Phillip

> [1] https://stackoverflow.com/questions/21718311/when-multi-thread- 
> program-receive-a-sigpipe-signal-because-send-which-thread-wo