#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: |
Description
A number of places assume that this is never the case.
This can cause problems when ntp adjusts the time.
Change History (7)
comment:1 Changed 5 years ago by
Status: | new → assigned |
---|
comment:2 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
- r15365 converts almost all
time.time()
calls to a os_util wrapper namedmonotonic_time
(defaults to still usetime.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.
comment:3 Changed 5 years ago by
comment:7 Changed 17 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1470
Note: See
TracTickets for help on using
tickets.
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:
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?