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 absolute). 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). Anthony