[chubot]

I'm not sure I understand this example. Signals allow the program to receive a notification whether they are blocked on I/O or running on the CPU (and receive it immediately in the latter case).

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.

http://man7.org/linux/man-pages/man2/signalfd.2.html

I'm not saying signals are fun, but I don't think you've proposed anything different/better.

[zAy0LfpBZLC8mAC]

> Signals allow the program to receive a notification whether they are blocked on I/O or running on the CPU (and receive it immediately in the latter case).

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.

[adrianratnapala]

Sorry if I gve the impression I was prpoposing something new. I was trying to explain, in concrete terms, to a someone who is "not an operating systems person" what existing OSes do.

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.