Idea: waitfd()

[Scott James Remnant]

In the latest kernel releases, we got two exciting new facilities:
signalfd() and the timerfd_*() series.  These allow us mortal
application developers to deal with signals and timers in our main loop
using just read().

To my mind, there's an obvious third one missing for which the name
"waitfd()" seems as good as any.  It probably helps understand the
context if you know signalfd()/timerfd_*()


waitfd() would accept a pid (like waitpid, or perhaps an idtype/id like
waitid) and return a file descriptor (like signalfd does).

This file descriptor may be monitored by select()/poll()/epoll() and
would poll for input if a matching process is in the wait queue.

Calling read() on the file descriptor would return siginfo_t (or
similar) structures filled in as for waitid() and remove the entry from
the wait queue.


In effect, the following code would be identical (assuming waitid-like
syntax):

	fd = waitid (-1, P_ALL, 0);
	read (fd, &siginfo, sizeof (siginfo));
--
	waitid (P_ALL, 0, &siginfo, 0);

But with the advantage that we can now select()/poll()/epoll() on the
wait queue, rather than having to remember to call wait() within the
main loop body.


This means that the main loop can be completely generic, since all
events of interest can now be discovered using read().

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20080528/d02b495f/attachment.pgp