bug report: [ #447945 ] time.time() is not non-decreasing

Skip Montanaro skip at pobox.com
Sat Aug 4 17:43:53 CEST 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