[adrianratnapala]

Signals are the user-space equivalent of a hardware interrupt. It's true that almost any computer that does anything useful in the real world needs to be notified about that world using interrupt service routines (ISRs). But that doesn't mean user programs need interrupts. OSes can and do use interrupts as a cues to notify processes via very different abstractions. Heres one way:

  User Process 99:  
    read socket Foo.
  Kernel:
    socket Foo has no data yet, 
       move 99 from the "running" list to the "sleeping" list.
    run process 86
  User Process 86:
    do stuff
  << HARDWARE INTERRUPT!>>
  Kernel:
    Notice that 99 is waiting for this packet (via socket Foo).
    Copy network data into 99's read buffer.
    Move 99 back to the "running" list.
    Run some processes, soon enough 99 gets a turn.
  User process 99:
    Oh good!  I have data.

This sort of interface is usually much more useful for user applications than having the equivalent of their own ISR becuase it doesn't just send a notification -- it also controls the flow of the main application in a sane way. Simple, non-interactive applications can do this kind of blocking I/O all day long.

More responsive applications need some kind of event loop. I.e. instead of blocking on an concrete I/O resource, they block notification service which tells them what I/O is available. In very different ways, Windows messages and Unix select()/poll() both do this.

The end result is usually a callback driven program. This is slightly similar to signals/ISRs (since signals are a kind of callback) -- but the game-changing difference is that the callbacks are only called when the application has voluntarily gone back to the event loop.

[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.