From c3c616c3d193c211bd435380593a20ec13e07b7b Mon Sep 17 00:00:00 2001 From: Victor Stinner Date: Thu, 3 Sep 2015 00:13:46 +0200 Subject: [PATCH] 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. --- Python/pytime.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/Python/pytime.c b/Python/pytime.c index 02a93749c71..e46bd42f547 100644 --- a/Python/pytime.c +++ b/Python/pytime.c @@ -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; }