<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On May 15, 2013, at 9:13 AM, Joe Flowers wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div><div>Carl and Hendrik,<br><br></div>Thank you very much for your comments and expertise.  <br><br></div>You are right, I'm mixing up thread-safety and re-entrantcy.  Sorry.<br>

<br></div>With Hendrik's advice on not cancelling threads to prevent a deadlock or zombie-type threads, I'm now more concerned with thread-safeness.<br></div></div></div></div></div></div></blockquote><div><br></div><div>You're heading pretty far down a tangent with malloc etc. System calls won't be your problem.</div><div><br></div><div>Assuming you're using pthreads (or the windows equivalent), the main thing you need to worry about is the few ffmpeg functions that aren't re-entrant, mainly codec opening, selection and closing. Each context you open is as thread-safe as you make it, and you definitely don't need to wrapper all ffmpeg calls.</div><div><br></div><div>Look for the lock manager stuff, or put your own critical section around the non re-entrant functions. That's about it. On a modern OS, trying to second guess threading on the system libraries is a folly.</div><div><br></div><div>Bruce</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><br>1.<br>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?<br>

<br>2.<br></div>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().<br>

</div><br></div>Thanks!!!<br><br></div>Joe<br>-------------------<br><br><div><div><br><br><br><div><div><br><div><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Wed, May 15, 2013 at 11:37 AM, Carl Eugen Hoyos <span dir="ltr"><<a href="mailto:cehoyos@ag.or.at" target="_blank">cehoyos@ag.or.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">Joe Flowers <joe.flowers@...> writes:<br>
<br>
> I need to use the libav* APIs (specifically the audio<br>
> codecs) in a thread-safe way, but they seem to be full<br>
> of malloc()s and free()s which aren't re-entrant.<br>
<br>
</div>My malloc manual says that it uses mutexes "internally to<br>
protect the memory-management data structures employed by<br>
these functions" (alloc, free, etc.) to avoid corruption.<br>
Or do I miss something?<br>
<br>
Audio codecs generally don't use multi-threading and<br>
should therefore not require special treatment.<br>
<br>
Carl Eugen<br>
<br>
_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
</blockquote></div><br></div>
_______________________________________________<br>Libav-user mailing list<br><a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>http://ffmpeg.org/mailman/listinfo/libav-user<br></blockquote></div><br></body></html>