Quoting Andreas Rheinhardt (2020-11-12 21:51:28) > Derek Buitenhuis: > > On 10/11/2020 10:46, Andreas Rheinhardt wrote: > >> > >> +#define INIT_VLC_STATIC_FROM_LENGTHS(vlc, bits, nb_codes, lens, len_wrap, > >> \ > >> + symbols, symbols_wrap, symbols_size, > >> \ > >> + offset, flags, static_size) > >> \ > >> + do { > >> \ > >> + static VLC_TYPE table[static_size][2]; > >> \ > >> + (vlc)->table = table; > >> \ > >> + (vlc)->table_allocated = static_size; > >> \ > >> + ff_init_vlc_from_lengths(vlc, bits, nb_codes, lens, len_wrap, > >> \ > >> + symbols, symbols_wrap, symbols_size, > >> \ > >> + offset, flags | > >> INIT_VLC_USE_NEW_STATIC); \ > >> + } while (0) > > > > If I am reading correctly, wherever you add/use this, you are adding > > non-thread > > safe global init code to a decoder. This is a huge step back and not > > acceptable. > > > > It should be made to properly use ff_thread_once if possible, or reworked. > > > The ff_init_vlc_... functions are inherently thread-safe: Everything is > modified only once and directly set to its final value; so it's no > problem if two threads are initializing the same static VLC at the same > time.
Strictly speaking it's still a race (and therefore UB), even if you store the same values. I suspect tools like tsan will not like it either. -- Anton Khirnov _______________________________________________ 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".