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