From: Thorsten Froehlich (froetho_at_[hidden])
Date: 2007-11-26 03:14:11
Anthony Williams wrote:
> The implementation uses an absolute time internally, since absolute times are
> composable --- though the win32 API calls are made with a timeout in
> milliseconds, it is the number of milliseconds until the supplied absolute time.
> This allows for multiple win32 API calls without having to work out how much of
> the timeout has elapsed --- this is done implicitly by the calculation of the
> number of milliseconds remaining.
> Ideally we would have a monotonically increasing timer which is independent of
> the system clock. Unfortunately, we don't have such a timer --- we have to rely
> on the system's idea of UTC time. If the clock is set back after the timeout for
> the wait has been chosen, but before the number of milliseconds to wait in a
> win32 API call has been calculated, the number of milliseconds will be rather
With all due respect, it should be clear that such a dependency on a
user-controlled setting that can indefinably block a program is simply not
an acceptable design choice for professional programmers. No matter what the
reason, infinite blocking behavior is a bug in the boost implementation and
must be fixed in boost, not elsewhere.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk