Yup. A lot of people, myself included, were under the impression that signalfd takes over from the normal signal-handling pathway: it doesn't.
It's particularly bad because the only way to get notified on a child exiting, in an event-handling architecture, is to wait for SIGCHLD notifications. (You can't call wait/waitpid because that's blocking; at best you can call it in a separate thread.) So even if all you're trying to do is write a program that runs a handful of children asynchronously, you have to incorporate signals into your architecture. And signalfd taunts you by providing siginfo with each notification, so you think you know which child exited -- but in fact, those siginfos could have coalesced, so this data is useless.
A friend claimed to me that siginfo is only useful for so-called synchronous signals (SIGSEGV, SIGILL, etc. -- stuff that you can't handle in an event loop anyway), which I'm inclined to believe, the more I think about it. So there's no reason for signalfd to have included siginfo.
Both wait() and waitpid() have a non-blocking mode (WNOHANG). So use SIGCHLD to decide when to check the status of the child processes, and waitpid() to actually do it.
There is a not-so-nice but very effective trick: Send the process you wish to check for a signal of '0' (using kill(pid, 0)), if that fails the process no longer exists.
This is kind of nasty in case your pids tick over very fast so you'd have to do this with a fairly high frequency to make sure you don't hit the same pid twice.
Fortunately this is hardly ever a problem but it is something worth thinking about when using the trick.
Thats why kqueue on the BSDs is nicer as it can listen for children. Plus process descriptors for children also make this easier, Linux should get these with the capsicum port eventually.
It's particularly bad because the only way to get notified on a child exiting, in an event-handling architecture, is to wait for SIGCHLD notifications. (You can't call wait/waitpid because that's blocking; at best you can call it in a separate thread.) So even if all you're trying to do is write a program that runs a handful of children asynchronously, you have to incorporate signals into your architecture. And signalfd taunts you by providing siginfo with each notification, so you think you know which child exited -- but in fact, those siginfos could have coalesced, so this data is useless.
A friend claimed to me that siginfo is only useful for so-called synchronous signals (SIGSEGV, SIGILL, etc. -- stuff that you can't handle in an event loop anyway), which I'm inclined to believe, the more I think about it. So there's no reason for signalfd to have included siginfo.