[Libav-user] Using the libav* libraries in a thread-safe manner?

Joe Flowers 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
> http://ffmpeg.org/mailman/listinfo/libav-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130515/de27cbcc/attachment.html>

More information about the Libav-user mailing list