> * 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.). 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.
The fact that a timer is a file garanties you the usage of an existing
infrastructure and existing APIs to use it. For example epoll_create(2)
returns you a file descriptor, and this enable you ( for example ) to drop
this file descriptor inside a poll set. Also you get the cleanup
infrastructure that otherwise you would have to code every time, for each
new object that you create, by yourself. Something like :
int timer_create(void);
int timer_set(struct timespec *ts);
and you can use epoll or poll to get the timer event, and close(2) to
destroy it. You get automatic compatibility with lots of nice stuff having
an object that is actually a file and I usually like it as idea.
> * I'm sure everyone would agree that passing an opaque "user context"
> pointer is necessary with each event.
I asked this about a week ago. It's _trivial_ to do in epoll. I did not
receive any feedback, so I didn't implement it. Feedback will be very much
appreciated here ...
- Davide
-
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/