On Sat, Sep 18, 2021 at 05:43:25AM +0200, Andreas Rheinhardt wrote: > In this case the current code tries to warn once; to do so, it uses > ordinary static ints to store whether the warning has already been > emitted. This is both a data race (and therefore undefined behaviour) > as well as a race condition, because it is really possible for multiple > threads to be the one thread to emit the warning. This is actually > common since the introduction of the new multithreaded scaling API. > > This commit fixes this by using atomic integers for the state; > furthermore, these are not static anymore, but rather contained > in the user-facing SwsContext (i.e. the parent SwsContext in case > of slice-threading). > > Given that these atomic variables are not intended for synchronization > at all (but only for atomicity, i.e. only to output the warning once), > the atomic operations use memory_order_relaxed. > > This affected nv12, nv21, yuv420, yuv420p10, yuv422, yuv422p10 and > yuv444 filter-overlay FATE-tests. > > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com> > --- > Of course, one could also use static atomic integers.
should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued
signature.asc
Description: PGP signature
_______________________________________________ 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".
