Re: [PATCH] /dev/epoll update ...

[Christopher K. St. John]

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 [e-mail]
DistribuTopia http://www.distributopia.com