The SettingBase transaction mechanism relies on timestamps generated via std::chrono::system_clock::now() that are used as transaction IDs. This assumes that subsequent calls to e.g. SettingBase::stage()` generate a new timestamp each time, so that the transaction IDs are distinct from each other.
This fails regularly in the unit tests for clang and emscripten, because the chrono::system_clock implementation doesn't give enough resolution to guarantee strictly monotonously increasing timestamps for each call to stage(). This is easiest to reproduce with a clang (18) release build and the "SettingBase basic test" in Disruptor_tests (see #ifdef __clang__ workaround there).
Review the overall approach, whether timestamps are a good idea in general or are inherently error-prone, or if e.g. high_resolution_clock can be used for emscripten and clang (even if that happens to work for the unit test, there might be still a conceptual issue using the timestamps though).
The
SettingBasetransaction mechanism relies on timestamps generated viastd::chrono::system_clock::now()that are used as transaction IDs. This assumes that subsequent calls to e.g. SettingBase::stage()` generate a new timestamp each time, so that the transaction IDs are distinct from each other.This fails regularly in the unit tests for clang and emscripten, because the chrono::system_clock implementation doesn't give enough resolution to guarantee strictly monotonously increasing timestamps for each call to stage(). This is easiest to reproduce with a clang (18) release build and the "SettingBase basic test" in Disruptor_tests (see
#ifdef __clang__workaround there).Review the overall approach, whether timestamps are a good idea in general or are inherently error-prone, or if e.g. high_resolution_clock can be used for emscripten and clang (even if that happens to work for the unit test, there might be still a conceptual issue using the timestamps though).