Davide Libenzi wrote:
> sys_epoll, by plugging directly in the existing kernel architecture,
> supports sockets and pipes. It does not support and there're not even
> plans to support other devices like tty, where poll() and select() works
> flawlessy. Since the sys_epoll ( and /dev/epoll ) fd support standard polling, you
> can mix sys_epoll handling with other methods like poll() and the AIO's
> POLL function when it'll be ready. For example, for devices that sys_epoll
> intentionally does not support, you can use a method like :
:( I was hoping sys_epoll would be scalable without increasing the
number of system calls per event.
Is it too much work to support all kinds of fd? It would be rather a
good thing IMHO.
I'm thinking that a typical generic event handling library (like in a
typical home grown server) takes a set of fds and event handling
callbacks. sys_epoll is obviously not so trivial to use in place of a
poll() loop, because the library needs to fstat() each fd that is
registered to decide if epoll will return events for that fd.
For that to work, it's important that you can determine, through
fstat(), whether sys_epoll will actually return events for the fd, or
whether a sigqueue event is needed to trigger the epoll read.
So, is it exactly _all_ sockets and pipes, and nothing else?
Btw, is the set of fd types supported by epoll the same as the set of
fd types supported by SIGIO? That would be convenient - and logical.
thanks,
-- Jamie (who thinks a lot about fast web servers)
-
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/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:40 EST