https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87679
Bug ID: 87679 Summary: std::this_thread::sleep_until sleeps too much for clocks faster than system_clock Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ddomenichelli at drdanz dot it Target Milestone: --- I have a simulated clock that is not steady and runs faster than the actual system clock. In libstdc++ 8.2, std::this_thread::sleep_until implementation for not-steady clocks is something like this: auto __now = _Clock::now(); while (__now < __atime) { sleep_for(__atime - __now); __now = _Clock::now(); } where sleep_for puts the thread to sleep for the expected number of seconds, but using the system clock. This works if _Clock is the system_clock or it is slower than system_clock, but it will always sleep too much if it is faster. I'm not sure if this is a real bug, since I believe that the standard that the call should return after at least the requested time, but for sure it is still not optimal. The workaround is to specialize std::this_thread::sleep_until for my clock, but I thought it was worth reporting the problem... Perhaps c++ "Clock" requirement should have a "real time factor" (that is not necessarily constant during the execution), that can be used to optimize sleep_until? (This would be good both for faster and slower clocks).