Re: Rép : User-land CoreAudio driver and Leopard
Re: Rép : User-land CoreAudio driver and Leopard
- Subject: Re: Rép : User-land CoreAudio driver and Leopard
- From: Jeff Moore <email@hidden>
- Date: Fri, 16 Nov 2007 14:22:20 -0800
On Nov 16, 2007, at 7:22 AM, Stéphane Letz wrote:
Some more questions, trying to understand the HP_IOThread class:
- in HP_IOThread::WorkLoop() the mIOGuard is locked before the while
loop. What happens for commands that come from a thread different
from the IO thread? (they are supposed to execute immediately, so
SHP_Device::StartCommandExecution is called trying to Lock the
mIOGuard, but since mIOGuard is alreadystill locked in
HP_IOThread::WorkLoop() ?? ) Is the mIOGuard unlocked somewhere so
that the pendind commands can be done?
This is what the command mechanism is for. It manages the operations
that need to synch against the IO thread and change things that are
manipulated on the IO thread.
Yes, mIOGuard is take right at the top of the work loop, but it is
also released each time the IO thread goes to sleep (the
mIOGuard.WaitUntil() call in the middle there). This is what allows
other threads that might be blocked synchronizing against the IO
thread to run.
- in HP_IOThread::WorkLoop(), commands coming from the IO thread
itself are pushed in mCommandList if IsSafeToExecuteCommand returns
false, then executed at the end of the IO cycle. But I see that some
commands may do some non real-time safe operations (memory
operations....), and are actually executed in the real-time thread...
Yes indeed they do, but they are doing so only at the behest of the
HAL client making the appropriate API call. Thus, any pain that it
causes is considered self-inflicted from the HAL's perspective.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden