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 Tuesday, March 12, 2002, at 08:23 PM, Stefan Arentz wrote:
On Mon, Mar 11, 2002 at 08:50:05PM -0500, Jim Magee wrote:
OHowever, the Mach equivalent does not work that way. It assures only
one handler thread per event, regardless of how many queues the event
source is a member of, sees the event. This, in turn, is actually
relied upon by Core Foundation's CFRunLoop() model (and all the higher
level event loops [Cocoa and Carbon] built on top of that). So, you can
guess, it's a pretty fundamental assumption in the way we do things
now. What I'm looking for are the places our expected semantics are the
same, and where they are different, so I know the requirements on the
common mechanisms that would sit below the knode level.

Hmm. I'm wondering if it really makes sense to combine the Mach and BSD
APIs in one. I think I can come with a clean solution on which both
waitevent, select and kevent() can be efficiently build and run but I
do not yet have a picture in my mind that also includes CFRunLoop().

We cannot combine the Mach and BSD APIs into one. And sorry if it sounded like I was suggesting that.

What I was suggesting was that an application is likely to be either CFRunLoop-based _or_ BSD waitevent/kqueues based. The preponderance of event sources used by a particular application will likely dictate which mechanism it will use. But there is always those one-or-two crossover event sources. The socket used by a CF application, or the Mach notification port used by a kqueues application. Today, the only solution is to have each application spin off another thread to use the "other" waiting mechanism for those handful of sources that don't fit under the current interface and then "reflect" them into an event on the main queue to wake up the main thread. Alternatively, the application could periodically poll for the event. Neither of these is a good choice.

We have been working towards a way to unify these things for the last 2-1/2 years so that there is a way (not always the most efficient way, but a way) to add some of these "not like the others" event sources to your particular set/queue. That's real tough with select() vs. mach_msg() (the heart of CFRunLoop), as the namespaces of their respective event sources is pretty fixed and disjoint (file descriptors vs. mach port names). Adding file descriptor wrappers around each Mach port is prohibitive (Mach ports are much lighter weight than file descriptors/socket heads).

However, kqueues relieves these restrictions on the BSD side, so it brings new hope (A kqueue event could actually describe a Mach port name, not just a file descriptor, given the right set of filters). On the Mach side, we could try the same thing (remove the restriction that each message contains information about the Mach port it arrived on). But that turns out to be too ingrained to change (raw messages are passed around, and everyone expects them to be ports). Besides, Mach ports are lighter weight. So, its not prohibitively expensive to associate a mach port with a file descriptor you want to wait on. But instead of a traditional Mach message queue port, we have been venturing down the path of creating different flavors of ports. One such flavor is a notification port. A level (not edge) triggered port with what amounts to filters on both the initial event delivery attempt and the subsequent actual event delivery. Sounds pretty familiar, eh?....but it was actually decided upon even before kqueues was published.

So, you see, its not the queue APIs we are looking to unify. Its the mechanism(s) employed by the event sources to reflect their status out to the queue to which they belong. Its just that those queues could take one of two forms, either mach_msg() based for CFRunLoop(), or kqueue()-based for BSD style things. At the very lowest level, they already have to be unified. There is only one scheduler, and one thread wait queue mechanism in the system. It's just a queue of how much on top of that can be common, before we hit the fork in the road based on queue style.

Is the source code for the CFRunLoop available in Darwin?


It's just mach_msg() on a portset at our level. But unlike traditional Mach, our ports can be in multiple port sets simultaneously, and you can still "read" [MACH_RCV_MSG] directly from the port even while it is in a port set(s).

--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.