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.
>> then the GetTickCount API is used as a baseline for the relative timeout,
>> 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 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk