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

[Casey Dahlin <cdahlin@redhat.com>]

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