Messages in this thread |  | 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/
|  |