Using clock() in threading on Windows

[Maxim Khitrov]

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 or shorter depending on which way the update went.

Would it not be better to use time.clock() instead? The resolution is
much better, and the value is not linked to system clock. Right now, I
replace the threading._time reference with clock in some of my
programs and everything works perfectly. Condition and Event timeouts
are precise down to the millisecond (resolution of the sleep
function), and I see no side-effects.

Is it possible to make that change part of the module itself (keeping
time() for linux systems), or can someone think of a reason why using
clock is a bad idea? I know that it's using QueryPerformanceCounter
for implementation, which has some known issues, but I still think
that the advantages outweigh potential faults.

- Max

 

[Martin v. Löwis]

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 duration).
As this is also what the Python script passes (in seconds),
it is best to leave issues of timer resolution to the operating
system (which we have to trust anyway).

As a consequence, the half-busy loops could go away, at least
on systems where lock timeouts can be given to the system.

Regards,
Martin

 

[David Bolen]

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
increased overhead (and latency as the timer increases) of the busy
loop. On windows, replacing it with an implementation using
WaitForObject calls with the same timeouts I would have used with the
Queue performed much better, not unexpectedly, but was non-portable.

The current interface to the lowest level locks in Python are
certainly generic enough to cross lots of platforms, but it would
definitely be useful if they could implement timeouts without busy
loops on those platforms where they were supported.

-- David