Should you be scared of Unix signals?
If you&#x27;ve ever read the Lions&#x27; Book commentary on 6th Edition Unix, you&#x27;ll notice that many parts of the API as implemented back there are pretty solid -- quality, well designed interfaces that have stood the test of time.<p>Signals are not one of those parts. The 6th Ed signal handling code reads to me as somewhat of an afterthought whose use cases were mostly &quot;kill the process for a fatal signal or terminal ^C&quot;, &quot;ptrace for a debugger&quot; and maybe SIGALRM. The data structures don&#x27;t allow a process to have more than one pending signal -- if a new one comes along the fact an old one was pending is simply dropped. Running a signal handler automatically deregistered it, leaving a race condition if two signals arrived in close succession (this is a well known bug fixed by BSD later). And EINTR is an irrelevance if signals are generally fatal but its effects spread like poison through every other kernel API if you need your program to be reliable even with signals being delivered.<p>The worst bugs and races were fixed up by the BSD folks and others, but the underlying concept is an unfortunate combination of &quot;basically irredeemable&quot;, &quot;indispensable&quot; (you have to have some kind of &quot;kernel tells you something has happened&quot; API, and signals are what we got) and &quot;insidious&quot; (thanks to EINTR). I think they&#x27;re a strong candidate for &quot;worst design decision in unix&quot;.<p>(PS: one of the reasons they stand out in 6th Ed is that so much of the rest of that code is so good!)