lkml.org 
[lkml]   [2000]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Linus Torvalds wrote:
> > 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.
>
> Oh, I agree. I'm not saying that my approach magically fixes bugs in user
> space ;)

With poll(), it was *not a bug* for the user code to drop events; with
your proposed interface, it *is a bug* for the user code to drop events.
I'm just emphasizing this because Simon Kirby (sim@stormix.com) posted
incorrectly that your interface "has the same semantics as poll from
the event perspective".

[ Linus explains why the level-triggered style is difficult ]

> - the "proactively remove events when the thing that triggerred them goes
> away" approach means that each anti-event (like a read that empties the
> buffer) needs to undo it's events, but it also needs to be careful that
> it doesn't undo combined events, and it needs to be very careful about
> races (new packet coming in), so the proactive remove actually ends up
> being less than trivial - and in a performance-critical section.

That's the approach I was thinking of. It should be about as difficult
as continuously maintaining an integer for each fd which matches what poll()
with a zero timeout on that fd would return. (The difference is that
as the bits of the integer change, you would move the fd's record in and out of
the ready list.) How hard is that?

> Implement it, and see. I bet you'll find that it gets really interesting
> when you have concurrent accesses to the same file descriptor etc.

Sure, but lots of the kernel is really interesting.
- 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/

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