Messages in this thread | | Linus Torvalds wrote: > > * Do you get an event whenever an fd is ready for something, or > > only when its readiness changes? (Presumably whenever an fd is ready for something?) > > Only when its readiness changes - probably with the addition that it would > simplify things that a new event always (unconditionally) gets added to > the event queue. > > Note that there are no races in this implementation - there is no way for > events to get lost, even trivially seen in SMP/threaded environments. > That's important.
But user code currently written for poll() has the luxury of dropping events because poll() will happily report on the current readiness of the socket every time. /dev/poll is level-triggered because it's trying to make conversion of poll()-based code easy. With your scheme, whatever user code is receiving the edges better darn well do something about them, because it's only going to get them once.
> The BSD kevent paper goes on about "level and edge triggered" and it > becomes a big thing for them, and they selected level-triggered events as > if it made any difference. And sure - it _does_ make a difference, but the > only difference is in how hard it is to implement, and level-triggered is > a noticeably harder.
I don't see why edge triggered is that much harder. All it adds is a layer which receives the edges and moves fds back and forth between a 'ready' list and a 'not ready' list. Easy as pie.
> The reason "edge-triggered" (ie only when an event changes) is preferable > is that it's MUCH simpler, and means that the "get_events()" system call > doesn't need to actually understand what the events mean at all.
Not much understanding is required on the part of the edge-to-level filter.
That said, the edge-to-level filter can be in userspace, and the kernel part can be just edge-triggered -- as long as the kernel delivers the downward edges as well as the upward edges. We could do that by adding NOTPOLLIN, NOTPOLLOUT, etc., i.e. events that are delivered when a socket becomes UN-ready for reading. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |