Messages in this thread | | | Date | Wed, 25 Oct 2000 08:05:20 -0700 | From | Simon Kirby <> |
| |
On Tue, Oct 24, 2000 at 04:12:38PM -0700, Dan Kegel wrote:
> 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".
I missed this because I've never written anything that drops or forgets events and didn't think about it. Most programs will read() until EOF is returned and write() until EAGAIN is returned with non-blocking sockets. Is there any reason to ignore events other than to slow down response to some events in favor to others?
I don't see why this is a problem as this interface _isn't_ replacing select or poll, so it shouldn't matter for existing programs that aren't converted to use the new interface.
In any case, I think I would prefer that the kernel be optimized for the common case and leave any strange processing up to userspace so that the majority of programs which don't need this special case can run as fast as possible. Besides, it wouldn't be difficult for a program to stack up a list of events, even in the same structure as it would get from the kernel, so that it can process them later. At least then this data would be in swappable memory. Heck, even from an efficiency perspective, it would be faster for userspace to store the data as it wouldn't keep getting it returned from a syscall each time...
Am I missing something else?
Simon-
[ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ sim@stormix.com ][ sim@netnation.com ] [ Opinions expressed are not necessarily those of my employers. ] - 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/
| |