jgmyers@netscape.com (John Myers) writes:
> If a connection is likely to be idle, one would want to use an async
> read poll instead of an async read in order to avoid having to
> allocate input buffers to idle connections. (What one really wants
> is a variant of async read that allocates an input buffer to an fd
> at completion time, not submission time).
Right. This does make sense for a server with thousands of idle
connections. You could have lots of unused memory in that case.
> Sometimes one wants to use a library which only has a nonblocking
> interface, so when the library says WOULDBLOCK you have to do an
> async write poll.
Right. I can see this too. This might be thorny for epoll though,
since it's entirely conceivable that such libraries would be expecting
level style poll semantics.
> Sometimes one wants to use a kernel interface (e.g. sendfile) that
> does not yet have an async equivalent. Accept/connect are in this
> class--there should be nothing to prevent us from creating async
> versions of accept/connect.
Right. However in this case, I think using poll is a stop gap
solution.
It would be better to give accept, connect, and sendfile (and
sendfile64) native status in AIO. Even if the implementations are not
going to be ready for a while, I think their spots in the API should
be reserved now.
That said, the first two points above convince me that there are valid
reasons why poll is also needed in AIO.
-- 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:01:06 EST