time.time() can go backwards

[Antoine Martin]

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

[Antoine Martin]

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

​CLOCK_MONOTONIC.

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)
1.3700509071350098
timeit.timeit(time, number=1000000)
0.04274415969848633

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?

[Antoine Martin]

• 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.

[Antoine Martin]

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

[Antoine Martin]

r15376 fixes the RPM packaging.

[Antoine Martin]

Similar fix applied to the Javascript code in r16441.

[Antoine Martin]

Caused a bug: #2038

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/1470