site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Jan 20, 2010, at 4:38 AM, Dave Keck wrote:

Hello,

Is there a reason that CFRunLoop is implemented atop Mach messages rather than a kqueue? If it were implemented atop a kqueue, not only would CFRunLoop maintain support for waking when a Mach message arrives, but it could also be awoken when data is available on an arbitrary file descriptor. (As far as I'm aware, the only way to do this currently is to spawn a secondary thread to monitor the descriptor and message the original thread to wake it.)

It seems a kqueue-CFRunLoop would improve efficiency quite a bit at no cost; I've written a lot of code that uses the secondary thread technique, and I know there's a lot of system APIs that do the same (CFFileDescriptor and CFSocket to name a few.)

I did notice that kqueues just gained support for monitoring Mach messages in 10.6 though, so perhaps CFRunLoop has just been waiting for support in the kernel?

Hi Dave, You are absolutely correct. I, too, was disappointed that CFRunLoops poll mach ports only- especially since gnustep polls file descriptors, which is much more useful. With a kqueue-backed runloop, one can poll file descriptors, signals, mach ports, timers, vnodes, and audit sessions. The runloop becomes a central dispatch loop, just as it should be. By the way, CFRunLoop's sources are available here: http://www.opensource.apple.com/source/CF/CF-550.13/CFRunLoop.c In the end, I simply wrote by own runloop which runs on all threads except the primary thread. Cheers, M _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com