From owner-freebsd-chat Tue Oct 24 23: 4:17 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 3F6DC37B479 for ; Tue, 24 Oct 2000 23:04:07 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9P62kh58482; Wed, 25 Oct 2000 01:02:46 -0500 (CDT) (envelope-from jlemon) Date: Wed, 25 Oct 2000 01:02:46 -0500 From: Jonathan Lemon To: Dan Kegel Cc: Jonathan Lemon , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025010246.B57913@prism.flugsvamp.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <39F6655A.353FD236@alumni.caltech.edu> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Oct 24, 2000 at 09:45:14PM -0700, Dan Kegel wrote: > If you haven't already, you might peek at the discussion on > linux-kernel. Linus seems to be on the verge of adding > something like kqueue() to Linux, but appears opposed to > supporting level-triggering; he likes the simplicity of > edge triggering (from the kernel's point of view!). See > http://boudicca.tux.org/hypermail/linux-kernel/2000week44/index.html#9 Yes, someone pointed me to those today. I would suggest reading some of the relevant literature before embarking on a design. My paper discusses some of the issues, and Mogul/Banga make some good points too. 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. kqueue() provides the ability for the user to choose which model suits their needs better, in keeping with the unix philosophy of tools, not policies. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message