• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AudioDeviceStop and ioProc
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: AudioDeviceStop and ioProc
      • From: Jeff Moore <email@hidden>
References: 
 >RE: AudioDeviceStop and ioProc (From: "Tim Dorcey" <email@hidden>)
 >Re: AudioDeviceStop and ioProc (From: Jeff Moore <email@hidden>)
 >Re: AudioDeviceStop and ioProc (From: Steve Checkoway <email@hidden>)
 >Re: AudioDeviceStop and ioProc (From: Jeff Moore <email@hidden>)

  • Prev by Date: Re: crashing in calls to AudioConverter on 10.3.9
  • Next by Date: GuardMalloc vs. auval
  • Previous by thread: Re: AudioDeviceStop and ioProc
  • Next by thread: Re: AudioDeviceStop and ioProc
  • Index(es):
    • Date
    • Thread