Date: Tue, 9 Dec 2008 19:04:03 +0000
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Casey Dahlin <cdahlin@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
       Scott James Remnant <scott@netsplit.com>
Subject: Re: [RFC PATCH] waitfd: file descriptor to wait on child processes
Message-ID: <20081209190403.2731dfd0@lxorguk.ukuu.org.uk>
In-Reply-To: <493EBD23.3020800@redhat.com>
References: <493EA441.1070706@redhat.com>
	<20081209170543.59b4fb73@lxorguk.ukuu.org.uk>
	<493EBD23.3020800@redhat.com>
Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street,
 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a
 Lloegr o'r rhif cofrestru 3798903
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1260
Lines: 25

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

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