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

[Casey Dahlin]

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

--
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/