glyph at divmod.com
glyph at divmod.com
Mon Sep 5 17:52:48 EDT 2005
On Mon, 5 Sep 2005 03:09:42 -0700 (PDT), Antony Kummel <antonykummel at yahoo.com> wrote:
>I noticed that the convention in Twisted is to measure
>time with python.runtime.seconds. This in turn uses
>time.time which is sensitive to the system clock,
>meaning that it may return decreasing values if the
>user sets the system clock to an earlier time between
>calls. This would likely break many things, no? Why
>not use time.clock or some combination between them?
time.clock() is unfortunately useless due to differences in its behavior between different platforms:
>>> import time; help(time)
Help on built-in function clock in module time:
clock() -> floating point number
Return the CPU time or real time since the start of the process or since
the first call to clock(). This has as much precision as the system
"CPU time" has absolutely nothing to do with "real time" and so using clock() to measure anything at all is pointless; its behavior is completely different between platforms.
There are other problems with time, too: it should return an integral number of milliseconds; the fact that it uses a float means that systems which cause the FPU to truncate double-precision floating point operations at single-precision (like DirectX) won't work at all with Twisted.
Basically, in order to provide a truly correct implementation of time, Twisted would need its own re-implementation of the 'time' and 'select' modules from the python standard library, as well as for all 3rd-party multiplexing and GUI libraries to take a different signature (since the convention is to use floats for time in Python) and nobody has yet had the time.
Clock skew is one of the easier issues to address; we just need an API to portably report a monotonically increasing real time in floating-point seconds, and for all the reactors to use it. Patches accepted :).
More information about the Twisted-Python