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

Casey Dahlin
2008-12-09T19:21:30Z

Alan Cox wrote:
>>> This propogates the fundamental braindamage of waitpid - the fact the
>>> notification only works on child process trees.
>>>
>>> Here is a more elegant suggestion - use epoll, inotify and friends fully
>>> on /proc process nodes.
>>>
>
>
>> Last I checked inotify was not supported in /proc, or at least most of
>> it. What kind of work load is it to change that?
>>
>
> I don't know but I think it would be the better approach to find it. That
> also separates notification of state to parents from the general problem
> of wanting to know when a service has died, which seems to be an ever
> more common point of interest on the desktop in particular.
>
>
Of course, using inotify on proc will not (and should not) actually reap
dead processes, meaning waitpid() isn't obviated by the change (though
now it is always called on a specific pid and is never expected to block
or EAGAIN). We also introduce a new gotcha for userspace programs: this
mechanism works identically for child and non-child processes, so a
process may or may not be waitable when returned. A simple "do not shoot
self in foot" should suffice for this though.

Also, it doesn't work if /proc hasn't been mounted, which just so
happens to matter for my particular use cases :)
> File content change notification for /proc is hard because the contents
> don't exist in the normal way and get updated but can be done if there is
> a wait queue for the job. Actual changes to structure (new directories
> etc) is in part a similar problem but there are clear points already in
> existence when the proc nodes are created/destroyed and thus notification
> can occur.
>
>
Changes to structure are more interesting in terms of this particular
problem anyway, and definitely simpler to capture.

--CJD