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/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:13 EST