Date: Thu, 6 Apr 2000 22:04:54 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Archie Cobbs <archie@whistle.com>, Jonathan Lemon <jlemon@flugsvamp.com>, freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <20000406220454.J80578@prism.flugsvamp.com> In-Reply-To: <200004070220.TAA92896@apollo.backplane.com> References: <200004070107.SAA97591@bubba.whistle.com> <200004070220.TAA92896@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 06, 2000 at 07:20:54PM -0700, Matthew Dillon wrote: > > :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]; > }; Um. One problem with this: the structure just went from 12 bytes (on a x86) to 32 bytes. I'm trying to keep this as small as possible, since I really want to minimize both the overhead of copying data back and forth, and the amount of space used in the kernel. I can see adding one more field (to 16 bytes), but doubling the size seems to be just too much. > 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). This essentially moves the state into the kernel. My feeling is that it's not the kernel's job to track the data; if the user wants to associate more state with the identifier, then it can maintain that in user space. The (ident/filter) should be enough to identify the event. > 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. The event is returned in the context of the calling thread; that is, the thread itself is what does the dequeing, so I'm not sure how this would be useful. Could you explain how this would work? > ipl: (future) Controls event retrieval ordering when multiple events > are pending, just like interrupt priority levels in a > hardware interrupt subsystem work. I was planning to simply handle this by creating multiple kq's. Then the caller builds its own priority mechanism by assigning the events to different kqueues, depending on what priority you want the returned event to be. > Finally, I think it would be prudent to change the timeout from > milliseconds to microseconds. I don't have any objection to this. -- Jonathan 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?20000406220454.J80578>