"Martin v. Löwis" writes:
> As a consequence, the half-busy loops could go away, at least
> on systems where lock timeouts can be given to the system.
I know that in some cases in the past I've had to bypass a Queue's use
of threading objects for waiting for a queue to unblock because of the
inc
> Would it not be better to use time.clock() instead?
If you really want to reconsider this implementation, I think it
would be best to use relative timeouts all the way down to the
system. In the specific case of Windows, WaitForSingleObject
expects a relative number of milliseconds (i.e. a wait
Maxim Khitrov wrote:
> The threading module uses time.time in _Condition and _Thread classes
> to implement timeouts. On Windows, time() typically has a resolution
> of 15.625ms. In addition, if the system clock is changed (though ntp,
> for example) it would reflect that change, causing the timeou
Greetings,
The threading module uses time.time in _Condition and _Thread classes
to implement timeouts. On Windows, time() typically has a resolution
of 15.625ms. In addition, if the system clock is changed (though ntp,
for example) it would reflect that change, causing the timeout to last
longer
