[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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 ( 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?


    [ Stormix Technologies Inc. ][ NetNation Communications Inc. ]
    [ ][ ]
    [ 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
    Please read the FAQ at

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