Re: [boost] Boost Threads Condition may block forever on clockchange

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-28 17:50:35

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.

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?

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.

> IIRC, WM_TIMECHANGE is broadcasted by the system on time changes since w2k 
> (and strongly recommended for applications before that). Whether that is 
> reliable enough would be up to you.

That's good to know.

Anthony