bug report: [ #447945 ] time.time() is not non-decreasing
Skip Montanaro
skip at pobox.com
Sat Aug 4 11:43:53 EDT 2001
zooko> After spending many hours tracking down weird race conditions in
zooko> Mojo Nation[1], I've finally realized that the problem is that we
zooko> assumed that `time.time()' would return non-decreasing answers.
zooko> In fact, successive calls to `time.time()' can return a *smaller*
zooko> number than previous calls, as demonstrated by this test (Python
zooko> 2.0 on debian woody):
zooko> import time
zooko> x = 0
zooko> while 1:
zooko> ox = x
zooko> x = time.time()
zooko> if x < ox:
zooko> print "this is WRONG: ox: %s, x: %s\n" % (ox, x,)
zooko> else:
zooko> print ".",
How long should I wait for this to print out an error message? On my
Mandrake 8.0 system running Python 2.1.1 I'm letting it run (and run, and
run) and have not so far seen a problem. Actually, I modified your script
slightly:
import sys
import time
x = 0
i = 0
while 1:
ox = x
x = time.time()
if x < ox:
print "this is WRONG: ox: %s, x: %s\n" % (ox, x,)
break
else:
i = i + 1
if i % 10000 == 0:
sys.stdout.write(".")
sys.stdout.flush()
so that it wouldn't print so many dots and exit once it detects an error.
Are you using threads, perchance? I can envision a situation in a
multithreading environment where two threads call time.time, but because of
scheduling differences you could be comparing them with a wrong assumption.
If the time() or ftime() calls on your Debian system can actually return
decreasing values, that's where the problem lies, not in Python.
--
Skip Montanaro (skip at pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/
More information about the Python-list
mailing list