> On Jun 20, 2023, at 8:39 AM, Hansen Jan Rørgård > <jan.r.han...@dk.saabgroup.com> wrote: > > Thanks for the clarification regarding the intended behaviour of > triggerEvent() ie. no queueing. > > Also thanks for the update to fix the race condition. As > std::atomic_flag::test() is a C++20 feature the compiler has to be fairly > new. As far as I can see support is added in GCC from version 11.1 with the > -std=c++20 option. For MSVC it is added in VS 2019 v16.11 with the /std:c++20 > option. > > Was it the intention that the fix should only be supported with C++20?
The intention was that the fix should be supported on any compiler that supports "std::atomic_flag” :-). That seems to include all recent versions of clang, BTW. But I have just installed a new version (2023.06.20) of the code that uses a similar implementation for event triggers even if "NO_STD_LIB" is defined. In that case, "fTriggersAwaitingHandling" is now implemented as an array of "Boolean volatile"s, rather than as a (volatile) 32-bit bitmap. This should make 'race conditions' less likely (perhaps even impossible) even if you define "NO_STD_LIB". (However, you should use the preferred, default implementation - that uses an array of "std::atomic_flag"s - if you can.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
