Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Who uses POSIX realtime signals and why?

I am not being flip I really don't get it. I just read a whole bunch of material on them and I can't figure out the use case. I am not talking talking so much about the API for which the advantages over things like signal() are clear enough. Rather it seems RT signals are meant to be user space generated but to what end? The only use seems to be a primitive IPC but everything points to them being a lousy form of IPC (e.g. awkward, limited information, not particularly efficient, etc).

So where and how are they used?

like image 900
ValenceElectron Avatar asked Jun 14 '11 15:06

ValenceElectron


People also ask

What is meant by real-time POSIX signal?

POSIX real-time signals include a value that is allocated to the receiver of the signal upon reception by sigwaitinfo() or sigtimedwait() . Signals are then handled according to the value allocated to the receiver. As a consequence, the number of signals sent always corresponds to the number of signals received.

What is a POSIX signal?

SIGABRT. The SIGABRT signal is sent to a process to tell it to abort, i.e. to terminate. The signal is usually initiated by the process itself when it calls abort function of the C Standard Library, but it can be sent to the process from outside like any other signal.

What are real-time signals in Linux?

9.4. Real-Time Signals. The POSIX standard introduced a new class of signals denoted as real-time signals; the corresponding signal numbers range from 32 to 63. The main difference with respect to standard signals is that real-time signals of the same kind may be queued.

In what cases does SIGKILL fail?

There are also two cases where SIGKILL doesn't work. With zombies obviously as you can't kill already dead processes and with init, which by design is ignoring SIGKILL signals. @jlliagre: Killing a zombie doesn't make sense, it's not alive to begin with.


2 Answers

First of all, note that Ben's answer is correct. As far as I can tell, the whole purpose of realtime signals in POSIX is as a realtime delivery mechanism for AIO, message queue notifications, timer expirations, and application-defined signals (both internal and inter-process).

With that said, signals in general are a really bad way to do things:

  • Signal handlers are asynchronous, and unless you ensure they do not interrupt an async-signal-unsafe function, they can only use async-signal-safe functions, which severely limits what they can do.
  • Signal handlers are global state. A library cannot use signals without a contract with the calling program regarding which signals it's allowed to use, whether it's allowed to make them syscall-interrupting, etc. And in general, global state is just A Bad Thing.
  • If you use sigwait (or Linux signalfd extension) rather than signal handlers to process signals, they're no better than other IPC/notification mechanisms, and still potentially worse.

Asynchronous IO is much better accomplished by ignoring the ill-designed POSIX AIO API and just creating a thread to perform normal blocking IO and call pthread_cond_signal or sem_post when the operation finishes. Or, if you can afford a little bit of performance cost, you can even forward the just-read data back to yourself over a pipe or socketpair, and have the main thread process asynchronously-read regular files with select or poll just like you would sockets/pipes/ttys.

like image 62
R.. GitHub STOP HELPING ICE Avatar answered Oct 23 '22 15:10

R.. GitHub STOP HELPING ICE


Asynchronous I/O.

Realtime signals are the mechanism for the kernel to inform your system when an I/O operation has completed.

struct aiocb makes the connection between an async I/O request and a signal number.

like image 34
Ben Voigt Avatar answered Oct 23 '22 15:10

Ben Voigt