Even more so because he doesn't mention the major danger zone of signals -- your code needs to be async-safe: https://www.securecoding.cert.org/confluence/disp

Even more so because he doesn't mention the major danger zone of signals -- your code needs to be async-safe: https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers https://www.securecoding.cert.org/confluence/display/seccode... Signal handlers will be called in the middle of execution of another function. There's no way to tell what locks may be held or what resources may be allocated/reserved; you can only safely call functions that have been evaluated to be and declared async-safe. That doesn't give you many options within a signal handler, but it also gives you a very good reason not to use them at all, if you can avoid them. On the BSDs and Mac OS X you can use kevent to handle signals via EVFILT_SIGNAL, which means you can avoid this mess altogether. On Linux, you have signalfd() which will let you monitor a file descriptor combined with select()/epoll()/etc to handle signals.