From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2006-04-10 12:37:16
An application I'm writing has the special requirement that it be able to
handle time-skews gracefully (like e.g. the daylight saving time or a user
changing the system time). Using Boost 1.32 (but I think the same applies to
later versions) it fails when I do things like this here:
xtime_get( &xt, TIME_UTC);
xt.sec += 2;
My approach now was to implement TIME_MONOTONIC as already sketched in
xtime.hpp, which was pretty straightforward (using timeGetTime() on win32).
However, I noticed that this won't work, because things like thread::sleep()
implicitly assume that the given time is from TIME_UTC and also only uses
that one to compare against - obviously won't work when one is the time since
system start and the other the time since 1970-01-01.
Two solutions came to mind:
1. Convert TIME_MONOTONIC to TIME_UTC.
This is more or less impossible to do reliably because a) timeGetTime()
overflows frequently (every 49 days) and b) it requires some kind of fixed
point that can be used for conversion, but that point simply does not exist
due to the limitations that drove me to implementing TIME_MONOTONIC in the
2. Add the clock type to the xtime structure.
This means that every place that a time is determined via xtime_get(), e.g. in
thread::sleep(), it uses the same clock type as the supplied object. I think
this version makes the most sense, right? Unfortunately this breaks
On a related note, why doesn't the threading lib offer any means to yield for
a certain time? In more than nine out of ten cases, this is the way I do
things, waiting for a certain point in time - like Boost.Thread does - is
rather the exception than the rule.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk