Anthony Williams wrote:
Johan Nilsson <r.johan.nilsson <at> gmail.com> writes:
[snip]
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.
Thanks for the suggestion, but I don't like the idea of forcing the creation of a background thread with a hidden Window just to handle the rare event of the system clock being changed during a wait. Also, you've still got to wake the waiting threads. You could do this with a manual-reset event, but how do you know to reset it?
[Caveat: just thinking out loud here] What about using user-mode APCs? Queue the user APCs from the background thread when the time changes. Whenever a thread is created, they could register a APC do-nothing callback (and remove on destruction). For all timed waits inside the thread library, use the alertable Wait functions (WaitXxxEx) and handle the APC delivery accordingly.
Another option is just to have the wait divide the wait up so it only waits for a maximum of some small period (e.g. 100ms or 10s or something) before waking up and checking the system time, and resuming waiting if the time has not expired. Again, this adds overhead.
Well, that's also susceptible to a race. You really can't know for sure how much time that elapses between your sleeps and wake-ups (and adjust the total according to that). / Johan