Messages in this thread | | | From | Erich Nahum <> | Subject | Re: epoll (was Re: [PATCH] async poll for 2.5) | Date | Tue, 22 Oct 2002 17:54:00 -0400 (EDT) |
| |
Davide Libenzi writes: > On Tue, 22 Oct 2002, John Gardiner Myers wrote: > > > > 1. re-arming the one-shot notification when the user gets EAGAIN > > > 2. re-arming the one-shot notification when the user reads all the data > > > that was waiting (such that the very next read would return EGAIN). > > > > > > #1 is what Davide wants; I think John and Mark are arguing for #2. > > > > No, this is not what I'm arguing. Once an event arrives for a fd, my > > proposed semantics are no different than Mr. Libenzi's. The only > > difference is what happens upon registration of interest for a fd. With > > my semantics, the kernel guarantees that if the fd is ready then at > > least one event has been generated. With Mr Libenzi's semantics, there > > is no such guarantee and the application is required to behave as if an > > event had been generated upon registration. > > There're a couple of reason's why the drop of the initial event is a waste > of time : > > 1) The I/O write space is completely available at fd creation > 2) For sockets it's very likely that the first packet brought something > more than the SYN == The I/O read space might have something for you > > I strongly believe that the concept "use the fd until EAGAIN" should be > applied even at creation time, w/out making exceptions to what is the > API's rule to follow.
There is a third way, described in the original Banga/Mogul/Druschel paper, available via Dan Kegel's web site: extend the accept() call to return whether an event has already happened on that FD. That way you can service a ready FD without reading /dev/epoll or calling sigtimedwait, and you don't have to waste a read() call on the socket only to find out you got EAGAIN.
Of course, this changes the accept API, which is another matter. But if we're talking a new API then there's no problem.
-Erich
- 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/
| |