Re: Unifying epoll,aio,futexes etc. (What I really want from epoll)

Matthew D. Hall wrote:
> The API should present the notion of a general edge-triggered event 
> (e.g. I/O upon sockets, pipes, files, timers, etc.), and it should do so 
> simply.

Agreed.  Btw, earlier today I had misgivings about epoll, but since
I've had such positive response from Davide I think epoll has
potential to become that ideal interface...

> *  Unless every conceivable event is to be represented as a file (rather 
> unintuitive IMHO), his proposed interface fails to accomodate non-I/O 
> events (e.g. timers,  signals, directory updates, etc.).#

...apart from this one point!

> As much as I appreciate the UNIX Way, making everything a file is a
> massive oversimplification.  We can often stretch the definition far
> enough to make this work, but I'd be impressed to see how one
> intends to call, e.g., a timer a type of file.

If it has an fd, that is, if it has an index into file_table, then
it's a "file".  No other semantics are required for event purposes.

This seems quite weird and pointless at first, but actually fds are
quite useful: you can dup them and pass them between processes, and
they have a security model (you can't use someone else's fd unless
they've passed it to you).  Think of an fd as a handle to an arbitrary
object.

OTOH look at rt-signals: a complete mess, no kernel allocation