Unix signals have been called garbage by some and "unfixable" by others [1]. The article [1] explains the evolution of signal handling, from sigvec(), sigaction

Unix signals have been called garbage by some and "unfixable" by others [1]. The article [1] explains the evolution of signal handling, from sigvec(), sigaction(), to signalfd() -- a rocky history fraught with problems, an article in the series "Unfixable designs". > So while signal handlers are perfectly workable for some of the early use cases (e.g. SIGSEGV) it seems that they were pushed beyond their competence very early, thus producing a broken design for which there have been repeated attempts at repair. While it may now be possible to write code that handles signal delivery reliably, it is still very easy to get it wrong. The replacement that we find in signalfd() promises to make event handling significantly easier and so more reliable. Another critic makes the case that "signalfd is [also] useless" [2]: > "UNIX[] signals are probably one of the worst parts of the UNIX API, and that’s a relatively high bar." Signals came up recently on HN when someone remarked that not even memset() is signal-safe! [3] All in all, working with signals correctly requires mastering a tremendous degree of complexity. Other platforms have provided simpler APIs, such as Structure Event Handling (SEH) [4]. [1] https://lwn.net/Articles/414618/ https://lwn.net/Articles/414618/ [2] article link from https://news.ycombinator.com/item?id=9564975 https://news.ycombinator.com/item?id=9564975 [3] https://news.ycombinator.com/item?id=13313563 https://news.ycombinator.com/item?id=13313563 [4] An HN comment describing how it's simpler: https://news.ycombinator.com/item?id=13323870 https://news.ycombinator.com/item?id=13323870 P.S. Please note that the views quoted above are not necessarily my views.