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

[ian4hu <hu2008yinxiang@163.com>]

Hi,

Gentle ping on this one.  It is queued in 'seen' as
iy/sigchain-recover-concurrent-pops, and the latest "What's cooking"
marks it as "Needs review".

A short recap: when two copies of the same signal reach two threads
nearly at the same time, the concurrent sigchain_pop() calls in the
handlers can unwind the chain by two levels instead of one, leaving
the process spinning in a handler that keeps re-raising the signal.
This is reachable with "git clone --depth 1" over ssh receiving two
SIGTERMs in quick succession, and only SIGKILL gets rid of the
process.

The patch leaves the push/pop fast path alone and only teaches the
"n < 1" guard in sigchain_pop() to fall back to the pre-chain
disposition, so the stuck handler's raise() terminates the process
just as a single delivery would.

Peff, I have Cc'ed you since you wrote the sigchain code.  I would
appreciate your thoughts on whether this "repair after the fact"
approach is acceptable, or whether you would rather see the chain
mutation serialized instead.  I also have a version that uses a
per-signal spinlock around push/pop, and can send it if that is
preferred.

Thanks,
ian4hu