--- 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:
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