Who uses POSIX realtime signals and why?

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.

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.

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.