Ghosts of Unix past, part 3: Unfixable designs

I think you've got the wrong idea. Signalfd isn't intended for "specialized" applications of signals (and I'm not sure how named pipes come into play at all). It would be nice to use for completely normal uses of signal handling: for example, it would be ideal for replacing a SIGCHLD handler in an application with an event loop: you're already waiting on fds to become readable/writable, so waiting on a signalfd fd to notify you of a child that finished is exactly what you want.

Most sensible such applications will already implement that by writing a signal handler for SIGCHLD which simply writes a byte into a pipe, and then has the event loop look for readability on that pipe. Signalfd would let you do that more easily -- if you could actually use it.