[FFmpeg-devel] [PATCH] avcodec thread safety fix
Mon May 25 23:52:34 CEST 2009
On Mon, May 25, 2009 at 11:53:22PM +0200, Andreas ?man wrote:
> Michael Niedermayer wrote:
> > On Mon, May 25, 2009 at 07:47:13PM +0200, Andreas ?man wrote:
> >> Michael Niedermayer wrote:
> >>> On Tue, May 12, 2009 at 04:08:55PM -0700, Daniel Steinberg wrote:
> >>>> So, one alternative would be to add a similar field to
> >>>> AVFormatContext, and propagate it to the AVCodecContext in
> >>>> av_new_stream(). It could also be propagated to all codec contexts in
> >>>> av_find_stream_info().
> >>>> Got a better suggestion?
> >>> a global function pointer?
> >> A patch with this attached.
> >> avcodec.h | 10 +++++++++-
> >> utils.c | 26 ++++++++++++++++++++++++++
> >> 2 files changed, 35 insertions(+), 1 deletion(-)
> >> ae73761c7266aa21721307a9be30086e1d4ab855 lock.patch
> >> Index: libavcodec/utils.c
> >> ===================================================================
> >> --- libavcodec/utils.c (revision 18941)
> >> +++ libavcodec/utils.c (working copy)
> >> @@ -65,6 +65,7 @@
> >> };
> >> static int volatile entangled_thread_counter=0;
> >> +static void (*codec_mutex_cb)(int lock);
> > thats a little unflexible
> > it at least should support multiple mutexes and be able to return an error
> > code like:
> > int mutex_cb(void **mutex, int lock)
> I agree on the error code. But i don't really see how / what the
> multiple mutexes are supposed to do?
pick a program that uses a mutexm chance are it uses more than 1
-> its unlikely we will never need a second mutex -> your proposed API is
unlikely to be sufficient in the future
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel