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

Reply via email to