John Gardiner Myers <jgmyers@netscape.com> writes:
> Charles 'Buck' Krasic wrote:
>
> In other words, you don't deny the problem. Instead, you work around
> it in user space.
Not exactly. I'm saying that the context in which /dev/epoll is used
(at least originally), is non-blocking socket IO. Anybody who has
worked with that API can tell you there are subtleties, and that if
they're ignored, will certainly lead to pitfalls. These are not the
fault of the /dev/epoll interface.
> Better to fix the API.
> The kernel has more information than user space and can do a better
> job.
I think we're talking across purposes.
I know this is the AIO list, but I think epoll has value independent
of AIO. They're complementary, not mutually exclusive.
> In the kernel, the problem can be fixed once and for all, not
> over and over again in each different wrapper library. It's not even
> as if the change would break programs correctly written to the old
> API, not that we particularly care about programs written to the old
> API.
I agree if you are talking about AIO as a whole. But epoll is more
limited in its scope, it really relates only to poll()/select not the
whole IO api.
-- Buck
-
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 : Wed Oct 23 2002 - 22:00:30 EST