lkml.org 
[lkml]   [2001]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] /dev/epoll update ...
Dan Kegel wrote:
>
> > My vote would be to always report the initial state, but
> > that would make the driver more complicated.
> >
> 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.
>

I agree that apps must properly handle incorrect hints, but
there's a difference between:

A) Signalling readiness when the fd really isn't ready. This
happens because of the nature of the universe, and isn't
avoidable (because the state can change after the signal is
sent but before the signal is received)

B) Not reliably signalling readiness when the fd is ready.
This is a bug, because it makes the mechanism 99%
useless (If you must manually poll all the fd's to make
sure there hasn't been a lost event, then you haven't
gained very much)

Not signalling initial state isn't as bad as (B), because the
app can code around it. But boy it's ugly, and because the
kernel already knows the information, it's 100% fixable in the
driver. (Although I'm not sure how much complexity it would
add to the driver, so I can't comment if the tradeoff it
worth it)


> 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.
>

Right, that's the solution mentioned in the BMD paper, and
that's what I've done. But it's (IMHO) ugly and (as you point
out) unexpected.

Anybody know what Solaris /dev/poll does? The man page I
read wasn't clear, and I don't have Solaris box to try it
out on.


--
Christopher St. John cks@distributopia.com
DistribuTopia http://www.distributopia.com
-
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/

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