site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Josh, I'm just trying to understand -- I sincerely appreciate the info :-) Regards, John Falling You - exploring the beauty of voice and sound http://www.fallingyou.com -josh On Apr 10, 2007, at 2:05 PM, jmzorko@mac.com wrote: Hello all ... ml_set_interrupts_enabled thread_block_reason thread_block uiomove selprocess select Regards, John Falling You - exploring the beauty of voice and sound http://www.fallingyou.com _______________________________________________ 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... Can I infer from this that the CPU time that the scheduler spends in my process, trying to determine which thread to run, is counted as time spent by my process e.g. is part of the time that 'top -ocpu' reports for my process actually the system scheduler checking thread states in my process? Or do I have it completely wrong? This just means that when shark sampled your process, that thread was blocked (not running) waiting for an event. I've a question -- under Darwin, is select() used to determine which threads are ready to run? Shark is reporting that our app spends most of its' time in select(), but the callstack that represents the majority of select() calls isn't our select() loop, it's something else: ... which makes me think that the kernel is using select() to determine when threads are ready. This makes some sense, as our app is very multithreaded. If this is the case, how can I get our (possibly too) multithreaded app to be kinder to the CPU under OSX? This email sent to site_archiver@lists.apple.com