lkml.org 
[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kqueue microbenchmark results
    On Wed, Oct 25, 2000 at 11:40:28AM -0700, Simon Kirby wrote:
    > On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote:
    >
    > > Consider a program which reads from point A, writes to point B. If
    > > the buffer associated with B fills up, then we don't want to continue
    > > reading from A.
    > >
    > > A/B may be network sockets, pipes, or ptys.
    >
    > Fine, but we can bind the event watching to the device or socket or pipe
    > that will clog up, right? In which case, we'll later get a write event
    > (just like with select()), and then once there is some progress you can
    > go back to read()ing from the original descriptor. This is even easier
    > than using select() because you don't have to take the descriptor out of
    > the read set and put it in the write set temporarily -- it will
    > automatically work that way.

    Yes, but with the above, you can't use get_event() as your main
    dispatching loop to do the read() call any more, since there may
    be no notifications pending in the queue. So you have to expand
    your main loop to include both get_event() as well as walk the
    "these descriptors may have partial data" list.


    Also, as Jamie pointed out, with kqueue/select you can do:

    kevent/read/write

    while with a pure edge-triggered scheme, you either must do:

    bind_event/read/.../read == 0/write

    Or maintain your own "this descriptor may have data" list.

    Also, consider the following scenario for the proposed get_event():

    1. packet arrives, queues an event.
    2. user retrieves event.
    3. second packet arrives, queues event again.
    4. user reads() all data.

    Now, next time around the loop, we get a notification for an event
    when there is no data to read. The application now must be prepared
    to handle this case (meaning no blocking read() calls can be used).

    Also, what happens if the user closes the socket after step 4 above?

    The user now receives a notification for a fd which no longer exists,
    or possibly has been reused for another connection. This may or may
    not make a difference to the application, but it must be prepared to
    handle it anyway. I believe that Zack Brown ran into this problem with
    one of the webservers he was writing.


    > > You can find my paper at http://people.freebsd.org/~jlemon
    >
    > I'll go and read it now. :)

    The paper talks about some of the issues we have been discussing, as
    well as the design rationale behind kqueue. I'd be happy to answer
    any questions about the paper.
    --
    Jonathan
    -
    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:45    [W:4.503 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site