traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Issue #24707: Remove assertion in monotonic clock 

Don't check anymore at runtime that the monotonic clock doesn't go backward.
Yes, it happens. It occurs sometimes each month on a Debian buildbot slave
running in a VM.

The problem is that Python cannot do anything useful if a monotonic clock goes
backward. It was decided in the PEP 418 to not fix the system, but only expose
the clock provided by the OS.
This commit is contained in:
Victor Stinner 2015-09-03 00:13:46 +02:00
parent 4912e7a3fd
commit c3c616c3d1
1 changed files with 0 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Python/pytime.c
View File

@ -533,10 +533,6 @@ _PyTime_GetSystemClockWithInfo(_PyTime_t *t, _Py_clock_info_t *info)
static int static int
pymonotonic_new(_PyTime_t *tp, _Py_clock_info_t *info, int raise) pymonotonic_new(_PyTime_t *tp, _Py_clock_info_t *info, int raise)
{ {
#ifdef Py_DEBUG
static int last_set = 0;
static _PyTime_t last = 0;
#endif
#if defined(MS_WINDOWS) #if defined(MS_WINDOWS)
ULONGLONG result; ULONGLONG result;
@ -627,12 +623,6 @@ pymonotonic_new(_PyTime_t *tp, _Py_clock_info_t *info, int raise)
} }
if (_PyTime_FromTimespec(tp, &ts, raise) < 0) if (_PyTime_FromTimespec(tp, &ts, raise) < 0)
return -1; return -1;
#endif
#ifdef Py_DEBUG
/* monotonic clock cannot go backward */
assert(!last_set || last <= *tp);
last = *tp;
last_set = 1;
#endif #endif
return 0; return 0;
} }