"Peter Dimov" <pdimov@pdimov.com> 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