Messages in this thread |  | | Date | Wed, 19 Sep 2001 12:12:00 -0500 | From | "Christopher K. St. John" <> | Subject | Re: [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/
|  |