Re: ::select() and threads
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Apr 10, 2007, at 8:00 PM, jmzorko@mac.com wrote: Josh, -Shawn _______________________________________________ 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? I'm just trying to understand -- I sincerely appreciate the info :-) I don't know but the time spent scheduling in likely so short you wont notice it (unless somehow you are thrashing the scheduler). Back to you question about what you saw in Shark... you can generally ignore threads that are found to spend most of their "time" blocked (thread_block, etc.). You can ask Shark to filter things like this so you can find the thread(s) that are actually doing something if you find you have something consuming a lot of CPU time. Basically a thread burning CPU will spend most of its time someplace other then in a function related to blocking a thread (Shark should sample that thread some place other then blocked). Also consider Shark's system trace feature which give a different view of how your threads are running. Often when first looking at a performance issue I will ask Shark to charge library calls to the calling process so I can find the location in my code that appear to be sampled most often by Shark. I then look these over and selectively dive down deeper if needed. This email sent to site_archiver@lists.apple.com
participants (1)
-
Shawn Erickson