Messages in this thread | | | Subject | Re: [PATCH] async poll for 2.5 | From | "Charles 'Buck' Krasic" <> | Date | 15 Oct 2002 19:45:27 -0700 |
| |
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/
| |