Re: [RESEND][RFC PATCH v2] waitfd

From: Davide Libenzi
Date: Sat Jan 10 2009 - 18:11:51 EST


On Sat, 10 Jan 2009, Scott James Remnant wrote:

> First, what we have today:
>
> sigemptyset (&mask);
> sigaddset (&mask, SIGCHLD);
>
> /* Block normal delivery and receive by sigfd instead */
> sigprocmask (SIG_BLOCK, &mask, NULL);
> sigfd = signalfd (-1, &mask, 0);
>
> for (;;) {
> read (sigfd, &fd_siginfo, sizeof siginfo);
>
> /* throw away fd_siginfo, we're reading SIGCHLD and
> * can't use it :-(
> */
>
> /* SIGCHLD means _at_least_one_ child is pending, there
> * may be more; so we have to loop AND expect to find
> * nothing
> */
> for (;;) {
> /* ARGH! waitid returns 0 with WNOHANG if there
> * are no children.
> *
> * AND the structure, despite being logically
> * the same, isn't the same as the signalfd
> * one :-/
> */
> memset (&w_siginfo, 0, sizeof w_siginfo);
>
> waitid (P_ALL, 0, &w_siginfo,
> WEXITED | WNOHANG);
>
> /* Did we find anything? */
> if (! w_siginfo.si_pid)
> break;
>
> /* NOW we have the siginfo_t for a recently
> * deceased process
> */
>
> mourn (&w_siginfo);
> }
>

That, once all the glamorous comments are removed, can be solved pretty
much with this much userspace code:

int waitfd(int flags) {
sigemptyset(&mask);
sigaddset(&mask, SIGCHLD);
sigprocmask(SIG_BLOCK, &mask, NULL);

return signalfd(-1, &mask, flags);
}

int waitfd_read(int fd, siginfo_t *si) {
for (;;) {
if (read(sigfd, &fd_siginfo,
sizeof fd_siginfo) != sizeof(fd_siginfo)
retrun 0;
memset(si, 0, sizeof *si);
waitid(P_ALL, 0, si, WEXITED | WNOHANG);
if (si->si_pid)
break;
}
return sizeof *si;
}


About the exit_signal, that would have made probably more sense for
it to be a parent property, instead of childs one. And be:

do_notify_parent(p, p->parent->exit_signal);

instead of:

do_notify_parent(p, p->exit_signal);

After all, is the parent that is going to make use of the notification,
not the child.



- Davide


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/