On Tue, 2008-12-09 at 11:41 -0800, Davide Libenzi wrote:

> On Tue, 9 Dec 2008, Casey Dahlin wrote:
> 
> > Linux already has signalfd, timerfd, and eventfd to expose signals, timers,
> > and events via a file descriptor. This patch is a working prototype for a
> > fourth: waitfd. It pretty much does what the name suggests: reading from it
> > yields a series of status ints (as would be written into the second argument
> > of waitpid) for child processes that have changed state. It takes essentially
> > the same arguments as waitpid (for now) and supports the same set of features.
> > 
> What's wrong in having a signalfd on SIGCHLD, than doing waitpid() once 
> you get the signal?
> 
Because SIGCHLD isn't a POSIX realtime signal, only one copy of it will
be queued at any one time -- even with signalfd(), and even though they
have different (useful) siginfo_t.

So if you have three children die in rapid succession, you only get the
siginfo for the first one.  Thus you still have to call
waitid()/waitpid() in a loop, and wait on everything.

Could the fact that you don't get signalfd notification of the
additional signals be considered a bug?  Or possibly a useful additional
feature?

If we were able to read all the queued SIGCHLD signals with signalfd
(preserving the one pending only behaviour of ordinary delivery), then a
loop like the following would be possible:

  sigemptyset (&mask);
  sigaddset (&mask, SIGCHLD);

  sfd = signalfd (-1, &mask, 0);

  for (;;) {
    read (sfd, &fdsi, sizeof (struct signalfd_siginfo));

    waitpid (fdsi.ssi_pid, 0, 0);
  }

So you only need to wait for each one individually.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?