Claudio Grondi wrote: > I mean, that using time.clock() solves the problem, because the output > of the following code:
On Windows that it. At least on Linux and Solaris, time.clock() returns CPU time. If time.clock() returns significantly different values before and after time.sleep(1), there's something seriously broken in sleep on such platforms. Anyway, what is the perceived problem? A) That sleep takes too much time, or B) that time measurements don't work right? If A), the problem is solved if what really happens is clock-setting glitches. If B), I see two options: - Use some proper external and stable time source. (It should be fairly trivial to build a little socket server that returns timestamps from a single source if no other source is available. See http://www.python.org/doc/lib/socket-example.html ) - If the clock-resetting is actually warranted because the system clocks lag so much, make sure this resetting is made more often, so that it never gets so much off track. Unless hardware is broken, or the clocks are changed so that they get more and more off track with time as the rest of us perceives it, there ought to be "negative sleeps" as well as sleeps much longer than 2 seconds. Of course, if you only look for longer sleeps than 2 secs, you won't see them. BTW, finding "negative sleeps" pretty much proves that it's the clocks, not actual delays, that cause problems... I guess a typical cause of clock setting problems is that one has two disagreeing time sources that both try to set the system times of the computers... -- http://mail.python.org/mailman/listinfo/python-list
