At 6:37 PM +0200 4/10/06, Ulrich Eckhardt wrote:
Hi!
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). [...]
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 [...]
Regrettably, good monotonic clock support seems to be weak at both the standards level and in actual implementations. Since boost.thread is largely a portable wrapper around the underlying OS-specific facilities, that probably makes it rather difficult for boost.thread to do better.
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.
Because a user can easily synthesize a relative time measuer on top of an interface that uses absolute times, but there is a race condition associated with a user attempting to specify an absolute timeout on top of an interface that uses relative timeouts. See, for example, the Rationale section for pthread_cond_timedwait() in the Single Unix Specification for more details.