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

Scott James Remnant
2008-12-13T02:58:10Z

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

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?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]