On Sat, Jul 25, 2015 at 1:21 PM, Mario Rohkrämer <[email protected]> wrote: > To clarify: It is supposed to fix a flaw in MinGW using non-atomic legacy > MSVCRT output routines. > > > > Am 25.07.2015, 20:17 Uhr, schrieb Mario Rohkrämer <[email protected]>: > >> People discussed an additional lock on a stats file output to avoid >> corruption with many threads: >> >> http://forum.doom9.org/showthread.php?p=1731547#post1731547
FWIW: I'm not certain the problem is necessarily in the atomic nature of the fprintf() calls. We're not ensuring the order of the last 2-3 frames correctly so making the fprintf blocking (and thus slow) is mostly hiding our bug. -- Steve Borho _______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
