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

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
> 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