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 large.
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. Thorsten