Re: Audio threads scheduling
Re: Audio threads scheduling
- Subject: Re: Audio threads scheduling
- From: Shaun Wexler <email@hidden>
- Date: Mon, 5 Apr 2004 12:57:44 -0700
On Apr 5, 2004, at 12:20 PM, William Stewart wrote:
The Window Server has a few threads, and a few priorities...
63 for its event handling - ie. very little work at highest user
priority
51 for its compositing.. that way user threads that have higher
priority tasks than UI (like disk reading data for a realtime
consumer) can get above the WS's UI...
Darwin source. CGS runs at 76, and max pri is 79 unless it gets
bumped to realtime.
It might ask for it - but you should look at ps axM to see if it
actually gets it at run time...
me 233 ?? 1.3 S 51 9:50.33 16:52.37
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/
CoreGraphics.framework/Resources/WindowServer -daemon
233 0.0 S 63 0:14.32 0:17.03
Real-Time???? for the WS??? Now that would be a bug and a big
problem...
I'm not entirely sure what you mean by CGS - are we talking about the
same thing here?
Yes, I had never actually checked ps -axM, and of course you are both
correct. I'd only looked thru the IOFrameBuffer and similar classes,
and remembered seeing the max priority allowed for the window server
was 76.
But that notwithstanding, I wished to illustrate that exceeding the
computation duration is a bad thing, because even though a thread may
be running with realtime priority, it can still be preempted if it is
within its available constraint window, unless preemption is disabled
on the thread.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.