[charles-salvia]

Basically, the main problem with signalfd is a problem with the Linux implementation of signals in general: if your program requires some kind of logic where each individual signal delivery somehow "counts" in some way, you may run into a problem because the kernel may coalesce/collapse multiple identical signals delivered consecutively into a single signal delivery. So if your program has some kind of logic that relies on responding to each individual signal, you may have a problem. (Note that this problem does not apply to POSIX real time signals.)

But as far as I know, the only reason you'd ever care to actually count individual signal delivery events is with SIGCHLD. So when waiting for SIGCHLD, using signalfd is not sufficient. You'd need to also use one of the wait/waitid/waitpid variants to ensure that you can respond appropriately to each individual SIGCHLD delivered.

[mtanski]

On the flip side of coalescing you can end in a situation where volume of signals leads to grinding down in the consumer or worse consumer hanging.

What do you do in that situation? You can force back pressure semantics on senders but then those can grind down, a lot of classic Unix tools were never built with that case in mind.

You could even argue that for signals coalescing should be preferred behavior and multiple signals could be merged together SIGIO, SIGCHLD. In SIGIO you can merge signals impacting FD, with SIGCHLD you should already be running waitpid with WNOHANG.

Sadly I don't believe this can uniformly apply to all signals (don't want to coalesce SIGSEGV/SIGBUS). Also siginfo_t complicates things quite a bit (since the info in there makes it hard to dedup). But such is life in POSIX.... we only now have the hindsight.

[ambrop7]

Yes, with SIGCHLD you can call waitpid(-1, &status, WNOHANG) in a loop until it fails, and you will collect all terminated children.