[Libav-user] Using the libav* libraries in a thread-safe manner?
joe.flowers at nofreewill.com
Wed May 15 18:13:22 CEST 2013
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.
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,
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().
On Wed, May 15, 2013 at 11:37 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Joe Flowers <joe.flowers at ...> 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
> Libav-user at ffmpeg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libav-user