Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Steve Checkoway <email@hidden>
- Date: Sun, 14 May 2006 01:27:27 -0700
On May 12, 2006, at 5:41 PM, Jeff Moore wrote:
AudioHardareUnload() won't return until the HAL has torn itself
down, including all it's knowledge of the registered call backs.
Okay, that's good to know.
How about removing property listeners? Can the property listener
still be called after AudioDeviceRemovePropertyListener() has
returned?
Yes. The specific case it comes up in is if one thread is removing
a listener at the same time the HAL is calling it on another
thread. Depending on the relative timing of the events, it can be
the case that RemoviePropertyListener() will return before the
other thread makes the call to your listener proc that was removed.
I suppose that makes sense. It'd probably require more locking (in
the HAL) to avoid that.
If so, what is the recommended way of handling that?
Be defensive in your listener proc. For instance, always check to
be sure that the user data is valid before dereferencing it.
That's good advice for dealing with any callback from a multi-
threaded OS like X. For example, the HAL runs into the very same
issue when fielding notifications from the audio drivers. The HAL
protects itself by using a unique, non-reusable token as the user
data with these notifications. The token maps to the actual object
that is going to act on the notification. This allows the HAL to
validate the token and only proceed if it maps to an actual object
rather than crash while de-referencing a stale pointer.
It still seems like there's a race condition if the token is valid
long enough to validate but the object handling the data is destroyed
between the lookup and the actual handling of the notification.
In my case it looks like it won't be an issue given the above since I
stop the IO procs, remove the listeners and then call
AudioHardwareUnload() before destroying the data that would be used
in any of the callbacks.
Thanks,
- Steve
_______________________________________________
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