Messages in this thread | | | Date | Thu, 8 Jan 2009 22:39:01 +0100 | From | Oleg Nesterov <> | Subject | Re: [RESEND][RFC PATCH v2] waitfd |
| |
On 01/08, Casey Dahlin wrote: > > Roland McGrath wrote: > >>> Since waitfd shouldn't consume the child termination notification > >>> waitfd should be more widely usable than the wait*() interfaces. > > > > waitid can be used that way with WNOWAIT. > > Yes, but waitfd does not have this flag. The reason being waitfd just > calls waitid internally, and there is no guarantee (afaik) that calling > waitid with WNOWAIT multiple times in succession will yield different > results each time. This breaks the streaming behavior of the descriptor.
Yes, do_wait(WNOWAIT) will return the same result on each call. Until the next child dies, and this child is closer to the head of ->children list.
But the reason is not that waitfd just calls waitid() internally. Let's suppose we add another helper (or waitfd_read() can do this by hand) so that read(waitfd_with_WNOWAIT_flag) correctly returns the info about all childs. Now, what should the next read() do?
Btw. It is not that I am trying to argue against sys_waitfd(), but do you have the "real life" example when it can be useful? Yes, poll(). But we have signalfd. SIGCHLD is not rt signal, but afaics this is not the problem actually. Just curious.
Oleg.
| |