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:
parent
4912e7a3fd
commit
c3c616c3d1
|
@ -533,10 +533,6 @@ _PyTime_GetSystemClockWithInfo(_PyTime_t *t, _Py_clock_info_t *info)
|
|||
static int
|
||||
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)
|
||||
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)
|
||||
return -1;
|
||||
#endif
|
||||
#ifdef Py_DEBUG
|
||||
/* monotonic clock cannot go backward */
|
||||
assert(!last_set || last <= *tp);
|
||||
last = *tp;
|
||||
last_set = 1;
|
||||
#endif
|
||||
return 0;
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue