Date: Thu, 26 Oct 2000 02:16:28 -0700 From: Gideon Glass <gid@cisco.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: Simon Kirby <sim@stormix.com>, Dan Kegel <dank@alumni.caltech.edu>, chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <39F7F66C.55B158@cisco.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> <20001025122307.B78130@prism.flugsvamp.com> <20001025114028.F12064@stormix.com> <20001025165626.B87091@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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... gid > > 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/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39F7F66C.55B158>