On Sat, 23 Dec 2017 22:32:36 +0100 Michael Niedermayer <mich...@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). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
