Re: ::select() and threads
Re: ::select() and threads
- Subject: Re: ::select() and threads
- From: Shawn Erickson <email@hidden>
- Date: Tue, 10 Apr 2007 20:23:57 -0700
On Apr 10, 2007, at 8:00 PM, email@hidden wrote:
Josh,
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.
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden