Michael Niedermayer: > On Tue, Sep 19, 2023 at 09:57:27PM +0200, Andreas Rheinhardt wrote: >> The API is very similar by the ProgressFrame API, with the exception >> that it no longer has an included AVFrame. Instead one can wait >> on anything via a ThreadProgress. One just has to ensure that >> the lifetime of the object containing the ThreadProgress is long >> enough (the corresponding problem for ProgressFrames is solved >> by allocating the progress and giving each thread a reference >> to it). This will typically be solved by putting a ThreadProgress >> in a refcounted structure that is shared between threads. >> It will be put to the test in the following commits. >> >> An alternative to the check for whether the owner exists >> (meaning "do we use frame-threading?") would be to initialize >> the progress to INT_MAX in case frame threading is not in use. >> This would probably be preferable on arches where atomic reads >> are cheap (like x86), but are there ones where it is not? >> >> One could also (guarded by e.g. an ASSERT_LEVEL check) actually >> track the progress for non-framethreading, too, in order to >> track errors even in single-threaded mode. >> >> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com> >> --- >> libavcodec/pthread_frame.c | 50 +++++++++++++++++++++++++++++++++++++ >> libavcodec/threadprogress.h | 37 +++++++++++++++++++++++++++ >> 2 files changed, 87 insertions(+) >> create mode 100644 libavcodec/threadprogress.h > > Seems to break build here with shared libs / clang > > CC libavcodec/pthread_frame.o > src/libavcodec/pthread_frame.c:1108:9: error: address argument to atomic > operation must be a pointer to non-const _Atomic type ('const atomic_int *' > (aka 'const _Atomic(int) *') invalid) > atomic_load_explicit(&pro->progress, memory_order_acquire) >= n) > ^ ~~~~~~~~~~~~~~ > /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expanded > from macro 'atomic_load_explicit' > #define atomic_load_explicit __c11_atomic_load > ^ > src/libavcodec/pthread_frame.c:1116:12: error: address argument to atomic > operation must be a pointer to non-const _Atomic type ('const atomic_int *' > (aka 'const _Atomic(int) *') invalid) > while (atomic_load_explicit(&pro->progress, memory_order_relaxed) < n) > ^ ~~~~~~~~~~~~~~ > /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expanded > from macro 'atomic_load_explicit' > #define atomic_load_explicit __c11_atomic_load > ^ > 2 errors generated. > src/ffbuild/common.mak:81: recipe for target 'libavcodec/pthread_frame.o' > failed > make: *** [libavcodec/pthread_frame.o] Error 1 > make: Target 'all' not remade because of errors. >
The original version of C11 did not allow to use atomic_load() on const-qualified atomic objects (presumably because on systems that don't have native support for atomic operations this might involve locking a mutex or so and this would involve writes); this has since been changed (see defect report N1807), yet your (presumably) ancient toolchain does not reflect that. I'll cast const away here and add a comment. - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".