exarkun at divmod.com
Mon Sep 5 14:04:09 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?
Twisted provides no real-time guarantees. The reliance on time.time() to return sensible results is just one aspect of this. If you're worried about scheduling in your application, you'll probably see more problems come up from Linux context switches, blocking syscalls (including disk I/O), system load, slow Python functions, Python's garbage collector, and user interference. Clock skew just doesn't come up much in practice, at least on any of the systems I run code on (NTP is your friend).
More information about the Twisted-Python