There definitely are correct patterns for handling signals -- the problem is more that there are also quite a lot of "looks plausible but has a race condition"

There definitely are correct patterns for handling signals -- the problem is more that there are also quite a lot of "looks plausible but has a race condition" ways to write code. The whole signals infrastructure in Unix has always been a bit dubious IMHO -- my impression from reading the Sixth Edition sources in the Lions book was that it looked like it had basically been put in to handle "signals are fundamentally fatal" cases like ctrl-C of a process from the terminal or SIGSEGV and friends, with the signal handler really only being there to do cleanup before the process exited. If that's all signals are doing then none of the race condition stuff matters (including the traditional "when a signal handler is called it resets to SIG_DFL" race that was fixed by BSD-style signals) and nor do you need to care about the enormous mountain of pain that is having to handle EINTR return values from system calls. But once the mechanism was there it got used for other things, many of which involved "the process receives and deals with signals as part of its normal continuing execution".