At 20:46 +0100 3/2/04, Mario Kleiner wrote: Ah ja, needs to be on uniprocessor as well, because of the preemptible kernel functions, which pose the same requirements as really parallel (==smp) threads... Right. We also need it because I/O Kit executes most 'interrupt' code on a workloop thread. These threads call up into BSD for things like disk I/O completion and network packet delivery. They must acquire the appropriate funnel on the way up to keep BSD data structures consistent. It's worth noting that the splxxx routines (eg splnet) are NOPs on Mac OS X. [Actually, they do some helpful debugging checks but no actual work.] This is fine because all BSD code runs under a funnel and all interrupt delivery is done by I/O Kit threads that acquire the funnel before calling up into BSD. There's a very short (and information dense) section of Technote 2028 that explains this. <http://developer.apple.com/technotes/tn/tn2028.html#MacOSXKernelThreading> But as introducing fine grained locking in an existing kernel is quite a time consuming and incremental endeavour, we probably shouldn't expect this to be completed in the near future? Can i assume that it will take rather a couple of months or years instead of a couple of weeks or months? We stated at WWDC 2003 that finer grain locking will be shipped as part of a post-Panther major OS release. At this time we've made no public schedule commitment, so I can't really comment. What about things like OpenGL, collecting keyboard responses or mouse button presses? Do the frameworks use Unix device files for communication with the device drivers (-> ioctls/read/write/mmap -> BSD calls -> block on funnel) or do they use the Mach-API? The main concern is not file i/o but querying the mouse and keyboard for user responses and OpenGL graphics output with well controlled timing, see below for reason. Most user space driver access on Mac OS X is done through obvious BSD API (networking and file system) or via the I/O Kit "user client" mechanism. See "IMOSX: Accessing Hardware From Applications" for information about this. <http://developer.apple.com/documentation/DeviceDrivers/Conceptual/AccessingHardware/index.html> However, my concern is that the frameworks might end up hitting BSD for silly reasons. For example, even something as trivial as getpid takes the kernel funnel (the first time you call it; the response is cached in user space). Frameworks, in general, are complex things, and it's very hard to predict how they behave in this respect. Worse yet, even if they do happen to avoid funnels in the current implementation, that's not part of their documented API and there's no guarantee that they'll maintain this behaviour in the future. * * * I didn't have time to read and respond to the rest of your post tonight. I'll try to get to it tomorrow. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.