Messages in this thread |  | | Date | Wed, 19 Sep 2001 10:39:03 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [PATCH] /dev/epoll update ... |
| |
On 19-Sep-2001 Dan Kegel wrote: > "Christopher K. St. John" wrote: >> The Banga, Mogul and Druschel[1] paper (which I understand >> was the inspiration for the Solaris /dev/poll which was the >> inspiration for /dev/epoll?) talks about having the poll >> return the current state of new descriptors. As far as I can >> tell, /dev/epoll only gives you events on state changes. So, >> for example, if you accept() a new socket and add it to the >> interest list, you (probably) won't get a POLLIN. That's >> not fatal, but it's awkward. >>... >> My vote would be to always report the initial state, but >> that would make the driver a little more complicated. >> >> What are the preferred semantics? > > Taking an extreme but justifiable position for discussion's sake: > > Stevens [UNPV1, in chapter on nonblocking accept] suggests that readiness > notifications from the OS should only be considered hints, and that user > programs should behave properly even if the OS feeds it false readiness > events. > > Thus one possible approach would be for /dev/epoll (or users of /dev/epoll) > to assume that an fd is initially ready for all (normal) events, and just > try handling them all. That probably involves a single system call > to read() (or possibly a call to both write() and read(), or a call to accept(), > or a call to getsockopt() in the case of nonblocking connect), so the overhead > isn't very high.
I think there's an advantage instead. With the usual scheme :
select()/poll(); recv()/send();
you always issue two system calls each time, while with :
while (recv()/send() == FAIL) { wait_event(); }
you're going to issue two calls only in certain conditions.
- Davide
- 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/
|  |