Xpra: Ticket #1470: time.time() can go backwards

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

Thu, 23 Mar 2017 09:55:35 GMT - Antoine Martin: status changed

status changed from new to assigned

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?

Thu, 23 Mar 2017 11:00:05 GMT - Antoine Martin: status changed; resolution set

status changed from assigned to closed
resolution set to fixed

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.

Thu, 23 Mar 2017 12:30:23 GMT - Antoine Martin:

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

Fri, 24 Mar 2017 09:26:48 GMT - Antoine Martin:

r15376 fixes the RPM packaging.

Fri, 21 Jul 2017 06:44:05 GMT - Antoine Martin:

Similar fix applied to the Javascript code in r16441.

Thu, 22 Nov 2018 17:06:17 GMT - Antoine Martin:

Caused a bug: #2038

Sat, 23 Jan 2021 05:25:09 GMT - migration script:

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