Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kqueue/kevent project

On Sunday, March 10, 2002, at 04:16 PM, Stefan Arentz wrote:
Would you accept a proposal for an underlying API or changes in the
current architecture that can support all event related mechanisms?
Or is that something that is already being worked on?

It's pretty much a given that the underlying mechanisms will have to change in order to support kqueues. When we have talked about this in the past, we have tried to conceptualize a model where all the Mach<->BSD interactions would be below the knode level on the BSD side. To some extent, our wait_queue_link structure is analogous to a knode (but work would have to be done in order to bring them more in line, like adding the filters support). It would be nice to keep the BSD side of things talking knodes (actually convert is a better word, as select() and SMB already talks to wait_queue_links) , and the Mach side of things talking wait_queue_whatever... We have much greater freedom on the Mach side, so I envision most of the compromises to happen on that side of the fence. You will probably want to work with me on that part, as I have already started to adapt the Mach side, heading in this general direction. But we have not already started the BSD side, so you efforts are much welcomed.

One "problem" the kqueues implementation presents: multiple threads sharing a kqueue.

If we were to try and replace the (proprietary) waitevent mechanism currently used by our Darwin streaming server and AFP file servers (and I think that should be a goal), we would have to determine the impact of multiple threads on the kqueue design. In particular, the only way I see to safely deploy kqueues in an environment with more than one thread waiting on them, is to use the ONESHOT approach (every source is removed from the kqueue as soon as it fires once). Otherwise, the level-triggered nature of kqueues would likely have every thread awakened for a single event. After the event source is "drained" it has to be added back into the kqueue. The kqueue papers go into some length about how adding an event source to a queue is more expensive under kqueues, but it doesn't happen all that often. Well, in one of these multi-threaded environments, I would imagine it happening on every event.

The waitevent mechanism is much like the kqueue mechanism, but not as general purpose. It also leaves the event source in the queue but disables it once an event fires (and a thread is awakened to handle it). The thread then re-enables it at some later point. Besides the performance benefits of this approach, it also keeps the management of what is in the queue of event sources disjoint from the handling of the events themselves. This can be a good thing.

We would need to understand the performance difference between these two approaches. If it really isn't that great a difference, then fine. We could probably take a tiny performance hit for the sake of using something standard. However, if the difference is significant, we probably would want to suggest a change back to the maintainers of kqueues. That change would likely be support for either a special kind of filter that allows for disablement (and re-enablement) of an event source while it stays in a queue, or a new set of disablement semantics in the APIs themselves.

About doing Darwin work in general:

I'm interested in taking on a kernel related project that I can spend
some reasonable amount of time on. Maybe this is not the correct thing,
and I wouldn't mind. But if there is a list of other things, todos or
some interesting research available than I would really appreciate a
copy of that ;) I'm sure there are a lot more people here on the list
who are interested in that. It's also good for the open source
mindset.

There is a Darwin todo list. This is where we keep a list of things that we think the community might have success doing. However, it is pretty sparse right now. There is also the bug tracking system, which we use to track all the feature requests as well as bugs. You might find something in there, not on the todo list. We probably should see if we can move more of the features to the Darwin todo list on a more regular basis.

Of course, this all depends upon people opening up feature request bug reports in the first place. If you would like to see a feature added to Darwin, open a report. Indicate that you would possibly like to tackle the work yourself, if you are so inclined. That way, we can get interested folks (including those inside Apple) hooked up.

--Jim
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: kqueue/kevent project (From: Stefan Arentz <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.