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

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

On 28/10/2026 14:47, ian4hu wrote:
> 
> If you prefer the thread-level fix, I am happy to build it: a
> git_pthread_create() wrapper that blocks SIGINT/SIGHUP/SIGTERM/
> SIGQUIT around pthread_create()

I think that is probably the safest solution (though it does not help 
for threads created external library code - I'm not sure if we have any 
instances of that). I'd be interested to hear what others think, so I'd 
wait a couple of days to see if anyone else comments before spending 
much time on it.

> - leaving SIGPIPE alone, since it is
> a synchronous signal and blocking it in workers turns deaths into
> EPIPE

Does it? I thought that happened when its disposition is set to SIG_IGN. 
Blocking a signal delays its delivery until it is unblocked, it does not 
ignore the signal.

> - plus a sigaction()-based chain that masks all signals while
> a handler runs.

When I wrote my last email I was thinking about blocking the signal that 
is being handled as sigaction() defers the signal that is being handled 
unless SA_NODEFER is passed. However, sigchain_push_common() sets the 
same handler for all the common signals so it is probably safer to block 
at least those as well as I'm not sure all our handlers are reentrant.

>  I would then drop this patch, or keep it as a
> separate last-resort series if you think the belt and braces are
> worth it.

I'd be inclined to drop it - if we're handling signals in a single 
thread that should avoid the issue.

Thanks

Phillip