From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-30 17:31:12
Johan Nilsson <r.johan.nilsson <at> gmail.com> writes:
> Anthony Williams wrote:
> > As far as I can gather, POSIX expects the latter. Windows only offers
> > relative timeouts, so we get the former, though there's a potential
> > race between calculating "now" vs changing the clock. If I had a
> > reliable way to abort a wait if the clock changed.
> For Windows: As you said yourself earlier, WM_TIMECHANGE is available.
> Create a hidden window and run the message loop in a worker thread to catch
> those msgs. This could presumably be implemented using some kind of lazy
> init to work transparently even for the DLL version of Boost.Thread.
It appears that the win32 API does provide a solution for this after all:
Waitable timers. According to the docs, when you specify an absolute timeout
for a timer it tracks clock changes.
I've checked in a new version that uses these where available. Since the
resolution of waitable timers is only about 10ms, if the wait is less than
20ms then that a simple relative wait is used (even if the initial target was
At the moment, this is only done for the interruptible waits (sleep and
condition::timed_wait), but a similar scheme could be used for all timed waits
(e.g. mutex timed lock).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk