[lkml]   [2001]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 :


you always issue two system calls each time, while with :

while (recv()/send() == FAIL) {

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.087 / U:1.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site