Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Shaun Wexler <email@hidden>
- Date: Tue, 23 May 2006 21:11:08 -0700
On May 23, 2006, at 8:25 PM, Steve Checkoway wrote:
Shaun Wexler wrote:
Beware: start/stop and other HAL notification callbacks may be
sent on arbitrary threads, often one of the IOProc threads. Do
not assume or rely on them being delivered on the dedicated
notification runloop thread. ;)
Surely it can't be sent on a an arbitrary thread! If it tried to
deliver a notification on thread 2 (in this case) it'd be in a for
a shock as there is no runloop being run. I could see it happening
on an arbitrary thread that the HAL owns or one I've told it to use.
Yes, it will. By arbitrary, I mean: any thread which calls [a
function which calls] a HAL function, the main thread and/or the
dedicated notification runloop thread, or any IOProc realtime
thread. You must be fully prepared in your callback handlers that
the function is executing on a realtime thread (often these will be
start, stop, and almost always for overloads). There are no
guarantees that your callback handler will be called on the runloop
thread that you've specified, and you must code defensively. These
are often the causes of "random CoreAudio bugs" which are in fact
blatant app bugs due to threading naïveté. Unfortunately this is the
way the HAL needs to behave; I think the documentation could use some
improvements in these areas.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
"Problems cannot be solved by the same level of thinking that created
them." - Albert Einstein
_______________________________________________
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