问题
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?
回答1:
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 Linuxsignalfdextension) 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.
回答2:
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.
回答3:
It's an old question, but still.
POSIX threads on Linux in glibc (NPTL) are implemented using two real time signals. They are hidden from user (by adjusting min/max number constants). All events where library call must be propagated to all threads (like setuid) are done via those: calling thread sends signal to all threads to apply the change, waits for acknowledgement and continues.
回答4:
There are other reasons to use the real time signals. I have an app that interacts with a variety of external devices, and does so through a combination of means (serial port IO, even direct addressing of some cards older than most people you know). This is, by definition, a "real time" app -- it interacts with the real world, in real world time, not in "computer time".
Much of what it does is in a daemon process that's in a main loop: handling an event, reading info, writing out results to serial ports, storing things in the database, and so on, and then looping around for another event. Other processes on the machine (user processes) read the info from the DB, display it, and so on. The user in these other processes can send various signals to the daemon to alert it of various conditions: stop, changed input data, and so on. For example, the user process sends a "stop" signal, the daemon's signal handler routine has about 2 lines of code, setting a flag variable. When the daemon gets a chance, and it's convenient, it stops. The "interrupt" code is very simple, quick, and non-invasive. But it serves the purpose, doesn't require complex IPC structures, and works just fine.
So, yes, there are reasons for these signals. In real time applications. If handled appropriately, they work just fine, thank you.
来源：https://stackoverflow.com/questions/6345973/who-uses-posix-realtime-signals-and-why