Re: How to safely remove an IOProc
Re: How to safely remove an IOProc
- Subject: Re: How to safely remove an IOProc
- From: "Paul Sanders" <email@hidden>
- Date: Mon, 8 Feb 2010 10:39:47 -0000
Jeff Moore said:
> If you note, this crash is at an address without a symbol.
> This likely means that either the destination of the jump was
> bad or could also mean that the stack itself were corrupt.
...
> That said, the code you posted is not going to work correctly
> if there are two IOProcs on the device, which can happen under
> lots of circumstances, especially if you are using multiple
> APIs like NSSound, QT, etc.
My IOProc calls a virtual function. If it gets called after I
believe I have shut the device down, the object will have been
deallocated, although you would think that my 'dispatcher' would
show up in the stack trace. But how could a memory corruption
bug affect the code, which is in a read-only segment? I am not
using any other relevant API's (to my knowledge), but in any
case, they would surely be registering their own IOProc's. Why
would any of that result in mine being called?
> Also, kAudioDevicePropertyDeviceIsRunning is a global property
OK, thanks, I will take that piece of code out.
> If you call AudioDeviceStop() from inside your IOProc, you do
> get the guarantee that your IOProc will not get called again
> after the IOProc has returned.
OK, thanks. That seems to be the only safe way to do it.
> Finally, you should consider migrating your code away from
> deprecated APIs like AudioDeviceGetProperty() and
> AudioDeviceRemoveIOProc.
To what? The Core Audio documentation is quite awful, frankly.
Thank you for your replies.
Paul Sanders
_______________________________________________
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