Hi:
I won't provide an example, just either do a sleep, or call a timed wait on a semaphore, mutex etc... with a long enough timeout (say 60s). While your thread is waiting, change the clock of your computer backwards by say 2h.
Your thread will be waiting 2h instead of 60s.
Even the boost APIs that seem to allow relative waits (wait_from_now) all end up specifying an absolute wake up time.
Jean
On Thu, Feb 17, 2011 at 2:17 AM,
<Viatcheslav.Sysoltsev@h-d-gmbh.de> wrote:
This works in most cases, except my application sometimes needs to adjust
the PC clock. If the PC clock is adjusted backwards in time, then these
function wait longer than they should (since the end time is fixed in the
future).
Given that and what Ion says:
"For cases when the system clock is advanced discontinuously by an operator, it is expected that implementations process any timed wait expiring at an intervening time as if that time had actually occurred."
I would consider the behavior (prolonged waiting) as a bug. Well, its even kind of showstopper one. Imagine a boost-based programm running into issue when ntp daemon adjust the clock backwards. Can you please distill a small test case demonstrating the problem for your environment?
-- Slava