Carl and Hendrik, Thank you very much for your comments and expertise.
You are right, I'm mixing up thread-safety and re-entrantcy. Sorry. With Hendrik's advice on not cancelling threads to prevent a deadlock or zombie-type threads, I'm now more concerned with thread-safeness. 1. I know when I configure and make FFMPEG, there is an "--enable-pthreads" option. If I am understanding things correctly, this particular option is not relevant to the thread safety of a C program calling the libav* APIs, correct? 2. I am using gcc on Ubuntu to compile and link to the libav* libraries and am wondering if I need to use a particular "-pthreads" option (or something else) with gcc to make sure I am using thread-safe C libraries to get a thread-safe malloc()? The reason I ask is because in Windoze one has to link with the mulithreaded C libraries (*MT.lib) to get a thread-safe version of malloc(). Thanks!!! Joe ------------------- On Wed, May 15, 2013 at 11:37 AM, Carl Eugen Hoyos <[email protected]> wrote: > Joe Flowers <joe.flowers@...> writes: > > > I need to use the libav* APIs (specifically the audio > > codecs) in a thread-safe way, but they seem to be full > > of malloc()s and free()s which aren't re-entrant. > > My malloc manual says that it uses mutexes "internally to > protect the memory-management data structures employed by > these functions" (alloc, free, etc.) to avoid corruption. > Or do I miss something? > > Audio codecs generally don't use multi-threading and > should therefore not require special treatment. > > Carl Eugen > > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user >
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
