Apple

I am not canceling the thread... I simply set the pthread cancellation mode to PTHREAD_CANCEL_ASYNCHRONOUS, as soon as the thread starts running in stead of the default mode of PTHREAD_CANCEL_DEFERRED,so I could stop the process immediately to see who caused the stop. With the default mode, it was possible that the when the thread has actually stopped, the cause of it had moved on. It behaves the same in either mode, I just changed modes for debugging. But it now appears, from the back trace, that the thread it self is causing the cancellation.

Ethan...

On Apr 6, 2010, at 11:22 AM, Doug Wyatt wrote:

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.