Date: Wed, 25 Oct 2000 19:08:48 +0200 From: Jamie Lokier <lk@tantalophile.demon.co.uk> To: Simon Kirby <sim@stormix.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Dan Kegel <dank@alumni.caltech.edu>, chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025190848.C2266@pcep-jamie.cern.ch> In-Reply-To: <20001025112709.A1500@stormix.com>; from sim@stormix.com on Wed, Oct 25, 2000 at 11:27:09AM -0400 References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Simon Kirby wrote: > > While an 'edge-trigger' design is indeed simpler, I feel that it > > ends up making the job of the application harder. A simple example > > to illustrate the point: what if the application does not choose > > to read all the data from an incoming packet? The app now has to > > implement its own state mechanism to remember that there may be pending > > data in the buffer, since it will not get another event notification > > unless another packet arrives. > > What applications would do better by postponing some of the reading? > I can't think of any reason off the top of my head why an application > wouldn't want to read everything it can. Pipelined server. 1. Wait for event. 2. Read block 3. If EAGAIN, goto 1. 4. If next request in block is incomplete, goto 2. 5. Process next request in block. 6. Write response. 7. If EAGAIN, wait until output is ready for writing then goto 6. 8. Goto 1 or 2, your choice. (Here I'd go to 2 if the last read was complete -- it avoids a redundant call to poll()). If you simply read everything you can at step 2, you'll run out of memory the moment someone sends you 100000 requests. This doesn't happen if you leave unread data in kernel space -- TCP windows and all that. enjoy, -- Jamie 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?20001025190848.C2266>