xpra icon
Bug tracker and wiki

Opened 5 weeks ago

Closed 5 weeks ago

Last modified 5 weeks ago

#1470 closed defect (fixed)

time.time() can go backwards

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 2.1
Component: core Version: trunk
Keywords: Cc:


A number of places assume that this is never the case.
This can cause problems when ntp adjusts the time.

Change History (4)

comment:1 Changed 5 weeks ago by Antoine Martin

Status: newassigned

Monotonic time is implemented in python 3.3 and later: time.monotonic and


For python2, we can use ctypes: http://stackoverflow.com/a/1205762/428751 but the problem here is performance:

import timeit
from time import time
from xpra.os_util import monotonic_time
timeit.timeit(monotonic_time, number=1000000)
timeit.timeit(time, number=1000000)

So using ctypes is 33 times slower than calling "time"!
And osx doesn't have a librt, win32 doesn't have support for monotonic clocks at all?

comment:2 Changed 5 weeks ago by Antoine Martin

Resolution: fixed
Status: assignedclosed
  • r15365 converts almost all time.time() calls to a os_util wrapper named monotonic_time (defaults to still use time.time())
  • r15366 + r15367 converts it to using a cythonized version, which is just as fast and actually monotonic

For win32 we would need to call GetTickCount64 and translate that into a time value... from a starting reference point ourselves. This would allow us to cimport the function from all the cython modules, saving conversion to a python type and back.

This will do. Tested on both Linux and macosx.

Last edited 5 weeks ago by Antoine Martin (previous) (diff)

comment:3 Changed 5 weeks ago by Antoine Martin

r15368 (+r15369 fixup) does implement it for win32 so we can cimport the function from all the cython modules.

comment:4 Changed 5 weeks ago by Antoine Martin

r15376 fixes the RPM packaging.

Note: See TracTickets for help on using tickets.