[FFmpeg-devel] [PATCH 2/5] lavc: replace and deprecate the lock manager

[wm4]

On Sat, 23 Dec 2017 22:32:36 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Dec 21, 2017 at 11:22:21PM +0100, wm4 wrote:
> > Use static mutexes instead of requiring a lock manager. The behavior
> > should be roughly the same before and after this change for API users
> > which did not set the lock manager at all (except that a minor memory
> > leak disappears).
> > ---
> >  doc/APIchanges       |   5 +++
> >  libavcodec/avcodec.h |   8 +++-
> >  libavcodec/utils.c   | 107 +++++----------------------------------------------
> >  libavcodec/version.h |   5 ++-
> >  4 files changed, 26 insertions(+), 99 deletions(-)  
> 
> Are all thread APIs users used with our lock manager compatible with this
> replacement ?

Yes, unless they explicitly disable threads in FFmpeg and used a lock
manager to compensate for it. But that would lose safety in other
places, where we already rely on pthread_once(), and would disable
useful features like frame threading.

Possibly we should add a note about this when the next release happens,
or disallow disabling building without thread support.

> Someone, possibly reimar, but i may misremember who it was. Talked in the past 
> about thread API incompatibilies
> I believe the concern was that the user APP used multiple threads, one for each
> decoder and one for the demuxer. But the locking used by the user app between
> its threads could be incompatible with the locking of our "pthread" locks.
> 
> If this is not an issue, then iam happy about this patch and the
> removial of the lock manager complexity.

I'm not worried about it, because FFmpeg uses the OS native threading
lib. Thus it's compatible with whatever else builds on native
threading. I don't even think it's possible to have threading that does
not build on the OS primitives, unless you do extremely hacky stuff
behind the libc (or ntdll on Windows).