John Gardiner Myers <jgmyers@netscape.com> writes:
> The epoll API is deficient--it is subtly error prone and it forces
> work on user space that is better done in the kernel. That the API
> is specified in a deficient way does not make it any less deficient.
You can argue that any API is subtly error prone. The whole sockets
API is that way. That's why the W. Richard Stevens network
programming books are such gems. That's why having access to kernel
source is invaluable. You have to pay attention to details to avoid
errors.
With /dev/epoll, it is perfectly feasible to write user level
wrapper libraries that help avoid the potential pitfalls.
I think it was Dan Kegel who has already mentioned one.
I've written one myself, and I'm very confident in it. I've written a
traffic generator application on top of my library that stresses the
Linux kernel protocol stack to the extreme. It generates the
proverbial 10k cps, saturates gigabit networks, etc.
It has no problem running over /dev/epoll.
IMHO, the code inside my wrapper library for the epoll case is
significantly easier to understand than the code for the case that
uses the legacy poll() interface.
If /dev/epoll were so error prone as you say it is, I think I would
have noticed it.
-- Buck
ps If anybody cares. I can give them a pointer to my code.
> Again, there is no rational justification for the kernel to not test
> the condition upon registration. There is ample justification for
> it to do so.
-
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 : Tue Oct 15 2002 - 22:00:59 EST