https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
--- Comment #15 from Mike Crowe <mac at mcrowe dot com> --- (In reply to Mike Crowe from comment #14) > I submitted an RFC glibc patch last year: > http://patchwork.ozlabs.org/project/glibc/list/?submitter=66786 I submitted an updated version earlier this year: https://sourceware.org/ml/libc-alpha/2017-06/msg01111.html There are a few minor niggles to address, but it seems that the greater hurdle now is that two respondents have requested that I raise this with the Austin Group. So, I have done so at: http://austingroupbugs.net/view.php?id=1164 If this attempt fails, then I think it would be preferable to switch libstdc++ std::condition_variable to use std::chrono::steady_clock as its primary clock (along with the necessary changes in gthreads to support creating a condition variable using CLOCK_MONOTONIC) and convert all other clocks to that clock. I personally think it's more surprising that: cv.wait_for(std::chrono::seconds(2)); risks waiting for potentially huge amount of time if someone changes the system clock, than cv.wait_until(std::chrono::system_clock::now() + std::chrono::seconds(2)); waiting for two seconds if someone changes the system clock just afterwards so that the wait should return immediately.
