Re: [boost] [Review] Formal Review of Proposed Boost.Chrono LibraryStarts TOMORROW

Subject: Re: [boost] [Review] Formal Review of Proposed Boost.Chrono LibraryStarts TOMORROW
From: Aaron Graham (aaron_at_[hidden])
Date: 2010-11-09 18:47:50

See this gcc bugzilla entry for a discussion I've had about chrono support
in the gcc implementation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861

Unfortunately, monotonic_clock support, even if it exists, is a transparent
lie. It's not so much a problem with the chrono library as it is a problem
with the thread library's use of chrono. A monotonic clock is used to
provide somewhat accurate/reliable wait times even in the face of changing
clocks, especially in the case of mutexes and condition variables.

When condition::wait_until is called with a monotonic_clock time_point, that
time_point is translated to a system_clock time_point. If the system_clock
is changed (via NTP, adjtime, settimeofday, etc) between when
convert_to<system_clock> is called and when the underlying posix call is
made, the very reason for using monotonic_clock defenestrates and splatters
all over the pavement. Depending on the magnitude of the clock change,
wait_until could hang forever.

In my opinion, all convert_to calls in the thread library should go to the
monotonic_clock, if available. Not system_clock. I couldn't get the gcc
people to understand this, so I won't be able to use <chrono> in the
standard library sans modification. Maybe boost will get it right?

Let me know if I'm missing a subtle point that moots my concerns.

Other than that, I think the this library is great. I need it badly. I
haven't looked over all the code yet, but what I've seen looks good.