From owner-freebsd-arch Thu Apr 6 13:10:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2076237B6EA for ; Thu, 6 Apr 2000 13:10:09 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA00439 for ; Thu, 6 Apr 2000 22:13:35 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA33727 for freebsd-arch@freebsd.org; Thu, 6 Apr 2000 22:10:00 +0200 (CEST) Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id C5DB137C062 for ; Thu, 6 Apr 2000 13:09:48 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id PAA22553; Thu, 6 Apr 2000 15:13:12 -0500 (CDT) (envelope-from jlemon) Date: Thu, 6 Apr 2000 15:13:12 -0500 From: Jonathan Lemon To: "Justin C. Walker" Cc: arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <20000406151312.E80578@prism.flugsvamp.com> References: <200004060609.XAA03090@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004060609.XAA03090@scv1.apple.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 04, 2000 at 11:09:09PM -0700, Justin C. Walker wrote: > On Wednesday, April 5, 2000, at 10:21 PM, Jonathan Lemon wrote: > > > I would like to solicit comments on the kqueue mechanism > > that I've been working on. Currently, it will report events > > for sockets, vnodes, and aio requests, and hopefully is > > designed to be extensible. > > > > An API document and rough code is at: > > > > http://www.flugsvamp.com/~jlemon/fbsd > > Hi, Jonathan, > > This looks quite similar to what we've done on Mac OS X (Darwin), which > you can check out at publicsource.apple.com. It's designed to replace, > architecturally, the use of select() in most applications. It is most > effective where there is a lot of activity on a lot of file descriptors. Yes, that is what initially motivated me to write this; having a scalable notification mechanism for a large number of descriptors. However, this is general enough that it can act as a general event mechanism, and isn't limited to file deescriptors. Right now, I have sockets and UFS vnodes connected, and I've converted the `tail' utility to use the new kqueue() mechanism, so the process immediately gets notified of changes to a file it is monitoring. There is also a hack to allow queueing an AIO event after the I/O has finished. Another possibility would be to make this a general `timer' mechanism, simply by allowing an EV_TIMER event to be hooked up directly to the kernel timing wheel, giving the application an unlimited number of timers. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message