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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-27 13:28:12

"Peter Dimov" <pdimov_at_[hidden]> writes:

> Anthony Williams:
>
>> If a relative timeout is specified (using e.g. 
>> boost::posix_time::seconds),
>> then the GetTickCount API is used as a baseline for the relative timeout, 
>> and
>> before each internal wait the current tick count is compared against the
>> baseline in order to determine the remaining time.
>
> We should probably think of a way to enable the use of a monotonic clock 
> with the absolute timeout overloads. It doesn't feel right to make the 
> relative overloads the only way to access the functionality. 

Yes, we should. However, absolute time is always going to have issues with
clock changes --- if I schedule for something now (2007-11-27 18:23:15 UTC by
the current clock) to run tomorrow (2007-11-28 18:23:15 UTC), does it schedule
for 24-hours from now, or for when-the-clock-reads the right time?

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.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL