https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
--- Comment #14 from Mike Crowe <mac at mcrowe dot com> --- (In reply to Jonathan Wakely from comment #13) > (In reply to Roman Fietze from comment #12) > > Sorry if it is inappropriate to ask for any changes, but how can it be, that > > there is no fix for this bug for years in any of the GCC releases? > > Because it's not possible to implement the C++ requirements purely in terms > of POSIX, so it requires a new API in the C library, which is complicated. > All the information you need to investigate that is provided in this bug > report and the enclosed links. I submitted an RFC glibc patch last year: http://patchwork.ozlabs.org/project/glibc/list/?submitter=66786 There were some objections but no-one seemed to outright say no. Unfortunately it is blocked waiting for Torvald Riegel's removal of the assembly "optimisation" for x86 and x86_64 before it can go in. This seems to be taking longer than I expected when I wrote the patch. > > With this bug condition_variable::wait_until is completely unusable on many > > I find that hard to believe. Well, it does make it unsafe to use in an environment where CLOCK_REALTIME can change arbitrarily which some may consider to equate to "unusable". However, in the intervening time I've become aware of the std::synchronic proposal ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0126r2.pdf ) and I've been wondering whether libstdc++ would be better off implementing support for that and then using it to build its own condition_variable implementation. I'm not sure whether I'm qualified to do that though. :) If we wanted to do something in the short term then we could consider flipping the default clock for std::condition_variable to be std::chrono::steady_clock where it is available. I suspect that most code is using a relative timeout anyway and isn't really expecting the timeout to change when the system clock changes.
