[lkml]   [2000]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
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
Please read the FAQ at

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