> So you have to be very careful to reset any masked signals before starting a child process
I don't see what this has to do with signalfd. That statement is true generically. Non-default Unix signal handling and subprocess management have never cooperated cleanly. The point to signalfd is to provide a simpler mechanism to integrate signals (which are a legacy API in almost all cases) with existing synchronization and event handling architectures, not to magically make them not suck.
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.
I am at a loss as to how you decided that was the "money quote". I saw it as an incidental aside as long as he was in the area, in a large post about signalfd, as evidenced by the, you know, 22 instances of the term "signalfd", including one in the title.
> So you have to be very careful to reset any masked signals before starting a child process
I don't see what this has to do with signalfd. That statement is true generically. Non-default Unix signal handling and subprocess management have never cooperated cleanly. The point to signalfd is to provide a simpler mechanism to integrate signals (which are a legacy API in almost all cases) with existing synchronization and event handling architectures, not to magically make them not suck.