[lkml]   [2000]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kqueue microbenchmark results
    On Thu, Oct 26, 2000 at 02:16:28AM -0700, Gideon Glass wrote:
    > Jonathan Lemon wrote:
    > >
    > > 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?
    > Depends on the implementation. If the item in the queue is the
    > struct file (or whatever an fd indexes to), then the implementation
    > can only queue the fd once. This also avoids the problem with
    > closing sockets - close() would naturally do a list_del() or whatever
    > on the struct file.
    > At least I think it could be implemented this way...

    kqueue currently does this; a close() on an fd will remove any pending
    events from the queues that they are on which correspond to that fd.
    I was trying to point out that it isn't as simple as it would seem at
    first glance, as you have to consider an issues like this. Also, if the
    implementation allows multiple event types per fd, (leading to multiple
    queued events per fd) there no longer is a 1:1 mapping to something like
    'struct file', and performing a list walk doesn't scale very well.
    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:0.021 / U:15.080 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site