Re: ExtAudioFileDispose blocking
Re: ExtAudioFileDispose blocking
- Subject: Re: ExtAudioFileDispose blocking
- From: Doug Wyatt <email@hidden>
- Date: Tue, 6 Apr 2010 11:22:19 -0700
It would appear that your async cancellation (however it is that you're doing that) is causing AudioFile's call to read() to encounter an EINTR error, for which the Unix-conforming response is to call pthread_exit(PTHREAD_CANCELED);
On Apr 6, 2010, at 9:01 , Ethan Funk wrot
> More info on the ExtAudioFileRead blocking/thread killing problem: I set the thread filler thread to async cancelation and set a break point in a debug procedure I pushed on the thread cleanup stack. After 35 hours, it tripped, and here is the thread backtrace from the breakpoint:
>
> #0 0x000370c0 in fpCleanUp at FilePlayer.cpp:513
> #1 0x914be61f in _pthread_exit
> #2 0x91493a0a in cthread_set_errno_self
> #3 0x91488ba7 in cerror
> #4 0x980d8302 in Cached_DataSource::ReadBytes
> #5 0x9808c634 in AudioFileObject::ReadBytes
> #6 0x9808c4cd in AudioFileObject::ReadPackets
> #7 0x9808c397 in AudioFileReadPackets
> #8 0x980e53d0 in ExtAudioFile::ReadInputProc
> #9 0x9808a60d in AudioConverterChain::CallInputProc
> #10 0x9808a1e2 in AudioConverterChain::FillBufferFromInputProc
> #11 0x9808a0c1 in BufferedAudioConverter::GetInputBytes
> #12 0x98089f7d in CBRConverter::RenderOutput
> #13 0x98089d27 in BufferedAudioConverter::FillBuffer
> #14 0x9808a09a in BufferedAudioConverter::GetInputBytes
> #15 0x9808e24c in Resampler2Wrapper::RenderOutput
> #16 0x98089d27 in BufferedAudioConverter::FillBuffer
> #17 0x9808a09a in BufferedAudioConverter::GetInputBytes
> #18 0x98089f7d in CBRConverter::RenderOutput
> #19 0x98089d27 in BufferedAudioConverter::FillBuffer
> #20 0x98089e8f in AudioConverterChain::RenderOutput
> #21 0x98089d27 in BufferedAudioConverter::FillBuffer
> #22 0x98089a9c in AudioConverterFillComplexBuffer
> #23 0x980e6130 in ExtAudioFile::Read
> #24 0x980dce5d in ExtAudioFileRead
> #25 0x0003998f in FilePlayer::fillRingBufferThread at FilePlayer.cpp:535
> #26 0x914b5fbd in _pthread_start
> #27 0x914b5e42 in thread_start
>
> Any idea what cerr and cthread_set_errno_self functions are, and why they are calling _pthread_exit? I would expect any errors encountered in Cached_DataSource::ReadBytes to get passed up the chain to the original ExtAudioFileRead. Why is it instead resulting in a _pthread_exit call? How can I prevent this? My gut instinct is to set the thread cancelation state to disable and run it again for a few days and see what happens, but it sure would be nice to know what's really going on.
_______________________________________________
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