From owner-freebsd-chat Wed Oct 25 10: 9:13 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp1.cern.ch (smtp1.cern.ch [137.138.128.38]) by hub.freebsd.org (Postfix) with ESMTP id 128FF37B4C5 for ; Wed, 25 Oct 2000 10:09:11 -0700 (PDT) Received: from pcep-jamie.cern.ch (pcep-jamie.cern.ch [137.138.38.126]) by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id TAA14791; Wed, 25 Oct 2000 19:08:58 +0200 (MET DST) Received: (from jamie@localhost) by pcep-jamie.cern.ch (8.9.3/8.9.3) id TAA02527; Wed, 25 Oct 2000 19:08:48 +0200 Date: Wed, 25 Oct 2000 19:08:48 +0200 From: Jamie Lokier To: Simon Kirby Cc: Jonathan Lemon , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025190848.C2266@pcep-jamie.cern.ch> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001025112709.A1500@stormix.com>; from sim@stormix.com on Wed, Oct 25, 2000 at 11:27:09AM -0400 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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