No, they don't. Just because signal handler code gets executed immediately, doesn't mean that the progam "receives" anything, as you cannot really touch anything that's also touched by the rest of the program, as you'd usually produce some form of race condition. The little that you can do safely usually is functionally equivalent to setting a flag for the rest of the program to process, which you can just as well achieve with any other "non-immediate" IPC mechanism, with much lower risk of getting it wrong.

> The application can integrate signals with its event loop with the self-pipe trick, or it can use Linux-specific APIs to have signals delivered over a file descriptor.

Which, for all itents and purposes, transforms them into yet another pipe/socket/event source, in wich case you might as well use one of the numerous other variants of those.

The self-pipe trick just shows that what most applications need is an event polling mechanism, not a preemptive callback. As for signalfd, I'd say that is exactly the kind of interface nemaar wants INSTEAD of traditional signals.