From owner-freebsd-arch Thu Apr 6 19:22: 1 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 A089237B62A for ; Thu, 6 Apr 2000 19:21:58 -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 EAA13243 for ; Fri, 7 Apr 2000 04:25:29 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA34925 for freebsd-arch@freebsd.org; Fri, 7 Apr 2000 04:21:54 +0200 (CEST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 17E1D37C1FE for ; Thu, 6 Apr 2000 19:20:57 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA92896; Thu, 6 Apr 2000 19:20:54 -0700 (PDT) (envelope-from dillon) Date: Thu, 6 Apr 2000 19:20:54 -0700 (PDT) From: Matthew Dillon Message-Id: <200004070220.TAA92896@apollo.backplane.com> To: Archie Cobbs Cc: jlemon@flugsvamp.com (Jonathan Lemon), freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code References: <200004070107.SAA97591@bubba.whistle.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Jonathan Lemon writes: :> 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.. Cool stuff! What about.. Ditto, it looks pretty good. I have a couple of suggestions (apart from thinking of cool new filters to add). First, change the kevent structure to align it, deal with OS porting issues, and make room for future additions (like direct support for threads) without introducing backward compatibility problems. You also need a user-defined data field that is both passed and returned so you can associate arbitrary information with an event. I use event mechanisms like this all the time in embedded work and having a user-defined field adds an order of magnitude more functionality. struct kevent { int ident; int thread; short reserved1; short ipl; short filter; short flags; long data; union { int idata; void *pdata; } udata; void *reserved2[2]; }; udata: user defined data is copied to the returned events so you can identify them by more then just their descriptor (for example, to associate a user structure with them that your event handling code then uses directly). thread: (future) Set thread to return event on, 0 to return the event on any thread (or the main thread), -1 to create a new thread on the fly to handle the event. ipl: (future) Controls event retrieval ordering when multiple events are pending, just like interrupt priority levels in a hardware interrupt subsystem work. Finally, I think it would be prudent to change the timeout from milliseconds to microseconds. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message