is the AudioFile API thread-safe ?
is the AudioFile API thread-safe ?
- Subject: is the AudioFile API thread-safe ?
- From: Benjamin Golinvaux <email@hidden>
- Date: Thu, 20 Feb 2003 14:25:46 +0100
Dear list members,
sorry for the "question bombing" on the AudioFile API :-)
I have a crash that really worries me (pasted below)
It looks like the OpaqueObject instances are somehow "linked" together
in an stl container.... do I get it right ?
furthermore, it looks as if accessing this container from two different
threads
create problems (i'm not *sure* this is the correct reason but it
really looks like)
is the AudioFile API thread-safe ?
Otherwise i might wrap AudioFileOpen and AudioFileClose in a mutex, but
i'd rather avoid mutexes when possible (although it really shouldn't be
a big
problem here in multitrack feeder threads, being given the buffering)
Please note the AudioFileID ARE different, but they are maybe
referencing the same physical file (both opened using fsRdPerm)
Thanks
Benjamin
Thread 3:
#0 0x94d32d7c in std::_Rb_tree<unsigned long, std::pair<unsigned
long const, OpaqueObject*>, std::_Select1st<std::pair<unsigned long
const, OpaqueObject*> >, std::less<unsigned long>,
std::allocator<std::pair<unsigned long const, OpaqueObject*> >
>::lower_bound(unsigned long const&)
#1 0x94d32c00 in std::map<unsigned long, OpaqueObject*,
std::less<unsigned long>, std::allocator<std::pair<unsigned long const,
OpaqueObject*> > >::operator[](unsigned long const&)
#2 0x94cb3008 in OpaqueObject::OpaqueObject[not-in-charge]()
#3 0x94ce3500 in AIFCAudioFormat::New()
#4 0x94cb82b0 in AudioFileOpen
#5 0x002cc33c in MESFPAudioFile::WrapAudioFileOpen(FSRef*,
OpaqueAudioFileID**) (MESFPAudioFile.cpp:474)
......
Thread 4 ***Crashed*****:
#0 0x94d26448 in
std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*,
std::_Rb_tree_node_base*&, std::_Rb_tree_node_base*&,
std::_Rb_tree_node_base*&)
#1 0x94d32fb8 in std::_Rb_tree<unsigned long, std::pair<unsigned
long const, OpaqueObject*>, std::_Select1st<std::pair<unsigned long
const, OpaqueObject*> >, std::less<unsigned long>,
std::allocator<std::pair<unsigned long const, OpaqueObject*> >
>::erase(std::_Rb_tree_iterator<std::pair<unsigned long const,
OpaqueObject*>, std::pair<unsigned long const, OpaqueObject*>&,
std::pair<unsigned long const, OpaqueObject*>*>,
std::_Rb_tree_iterator<std::pair<unsigned long const, OpaqueObject*>,
std::pair<unsigned long const, OpaqueObject*>&, std::pair<unsigned long
const, OpaqueObject*>*>)
#2 0x94cb7470 in OpaqueObject::~OpaqueObject [not-in-charge]()
#3 0x94ce563c in AudioFileObject::~AudioFileObject [not-in-charge]()
#4 0x94d34bcc in AIFFAudioFile::~AIFFAudioFile [in-charge deleting]()
#5 0x94cb8880 in AudioFileClose
#6 0x002cb8c8 in MESFPAudioFile::Close() (MESFPAudioFile.cpp:213)
.......
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.