[FFmpeg-devel] [PATCH 2/5] lavc: replace and deprecate the lock manager
nfxjfg at googlemail.com
Sat Dec 23 23:41:21 EET 2017
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).
More information about the ffmpeg-devel