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).
