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 really cripples 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.