Re: [RFC PATCH] waitfd: file descriptor to wait on child processes

Davide Libenzi
2008-12-13T04:29:55Z

On Fri, 12 Dec 2008, Scott James Remnant wrote:

> 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);
> }

And how about this?

sfd = signalfd(SIGCHLD);
for (;;) {
poll(sfd, POLLIN);
while ((pid = waitpid(0, &status, WNOHANG)) != -1)
process_child_death(pid);
}

- Davide