Re: kqueue microbenchmark results

[Jonathan Lemon <jlemon@flugsvamp.com>]

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.
--
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/