Date: Thu, 6 Apr 2000 19:20:54 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Archie Cobbs <archie@whistle.com> Cc: jlemon@flugsvamp.com (Jonathan Lemon), freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <200004070220.TAA92896@apollo.backplane.com> References: <200004070107.SAA97591@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004070220.TAA92896>