Date: Wed, 25 Oct 2000 11:40:28 -0700 From: Simon Kirby <sim@stormix.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: Dan Kegel <dank@alumni.caltech.edu>, chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025114028.F12064@stormix.com> In-Reply-To: <20001025122307.B78130@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Wed, Oct 25, 2000 at 12:23:07PM -0500 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > Or perhaps you receive a request to use a resource that is currently > busy. Does your application want to postpone the request, or read the > data immediately, even if the request can't be serviced yet? Assuming this "resource" has a way of waking up the process when it unclogs, then you can go back and read the remaining data later, which is what you would want to do anyway. > My point is that I can easily think of several examples as to where > this behavior may be beneficial to the application, and I use some of > them myself. You can indeed get the same result by forcing each and > every application that wants this behavior to implement their own > tracking mechanism, but this strikes me as error-prone and places an > undue burden on the application programmer. I can see that you could write it this way... I'm just trying to see if it's really needed. :) As I wrote in my last email to Jamie, you would need to implement a tracking mechanism in any case to avoid DoS attacks from clients or a case where a single client can clog up the reading from any other client. And you'd need to take the descriptor out of the read() set in the select() case anyway, so I don't really see what's different. > You can find my paper at http://people.freebsd.org/~jlemon I'll go and read it now. :) Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ sim@stormix.com ][ sim@netnation.com ] [ Opinions expressed are not necessarily those of my employers. ] 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?20001025114028.F12064>