Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(1284)

#22043: Use a monotonic clock to compute timeouts

Can't Edit
Can't Publish+Mail
Start Review
Created:
3 years, 3 months ago by victor.stinner
Modified:
3 years, 2 months ago
Reviewers:
cf.natali, pitrou
CC:
sasha, haypo, Charles-François Natali, devnull_psf.upfronthosting.co.za
Visibility:
Public.

Patch Set 1 #

Total comments: 6

Patch Set 2 #

Total comments: 10

Patch Set 3 #

Total comments: 9

Patch Set 4 #

Unified diffs Side-by-side diffs Delta from patch set Stats Patch
Doc/library/time.rst View 1 2 3 1 chunk +2 lines, -2 lines 0 comments Download
Include/pytime.h View 1 2 3 1 chunk +18 lines, -0 lines 0 comments Download
Lib/queue.py View 1 2 3 1 chunk +1 line, -4 lines 0 comments Download
Lib/sched.py View 1 2 3 1 chunk +1 line, -4 lines 0 comments Download
Lib/socketserver.py View 1 2 3 1 chunk +1 line, -4 lines 0 comments Download
Lib/subprocess.py View 1 2 3 1 chunk +1 line, -4 lines 0 comments Download
Lib/telnetlib.py View 1 2 3 1 chunk +1 line, -4 lines 0 comments Download
Lib/test/test_selectors.py View 1 2 3 1 chunk +1 line, -4 lines 0 comments Download
Lib/threading.py View 1 2 3 1 chunk +1 line, -4 lines 0 comments Download
Lib/trace.py View 1 2 3 1 chunk +1 line, -4 lines 0 comments Download
Modules/_threadmodule.c View 1 2 3 2 chunks +2 lines, -2 lines 0 comments Download
Modules/gcmodule.c View 1 2 3 3 chunks +3 lines, -3 lines 0 comments Download
Modules/socketmodule.c View 1 2 3 2 chunks +2 lines, -2 lines 0 comments Download
Modules/timemodule.c View 1 2 3 6 chunks +6 lines, -135 lines 0 comments Download
Python/pytime.c View 1 2 3 3 chunks +167 lines, -0 lines 0 comments Download

Messages

Total messages: 7
Charles-François Natali
+1 from me. It's useful (I've personally seen some applications break because of this, although ...
3 years, 3 months ago #1
haypo
http://bugs.python.org/review/22043/diff/12455/Modules/_threadmodule.c File Modules/_threadmodule.c (right): http://bugs.python.org/review/22043/diff/12455/Modules/_threadmodule.c#newcode62 Modules/_threadmodule.c:62: endtime.tv_nsec += microseconds % (1000 * 1000) * 1000; ...
3 years, 3 months ago #2
haypo
3 years, 3 months ago #3
Charles-François Natali
http://bugs.python.org/review/22043/diff/12553/Include/pytime.h File Include/pytime.h (right): http://bugs.python.org/review/22043/diff/12553/Include/pytime.h#newcode38 Include/pytime.h:38: Return 0 on success, raise an exceptio and return ...
3 years, 3 months ago #4
haypo
http://bugs.python.org/review/22043/diff/12553/Include/pytime.h File Include/pytime.h (right): http://bugs.python.org/review/22043/diff/12553/Include/pytime.h#newcode38 Include/pytime.h:38: Return 0 on success, raise an exceptio and return ...
3 years, 3 months ago #5
AntoinePitrou
http://bugs.python.org/review/22043/diff/12788/Modules/timemodule.c File Modules/timemodule.c (right): http://bugs.python.org/review/22043/diff/12788/Modules/timemodule.c#newcode906 Modules/timemodule.c:906: return PyFloat_FromDouble((double)tv.tv_sec + tv.tv_usec * 1e-6); So the nanosecond ...
3 years, 2 months ago #6
haypo
3 years, 2 months ago #7
http://bugs.python.org/review/22043/diff/12788/Modules/timemodule.c
File Modules/timemodule.c (right):

http://bugs.python.org/review/22043/diff/12788/Modules/timemodule.c#newcode906
Modules/timemodule.c:906: return PyFloat_FromDouble((double)tv.tv_sec +
tv.tv_usec * 1e-6);
On 2014/08/31 02:24:18, AntoinePitrou wrote:
> So the nanosecond resolution is being lost?

I'm not sure that we really supported nanosecond resolution before because the C
double type (IEEE 754) looses precision for large value.

According to my old and rejected PEP 410:
"The Python float type uses binary64 format of the IEEE 754 standard. With a
resolution of one nanosecond (10^-9), float timestamps lose precision for values
bigger than 2^24 seconds (194 days: 1970-07-14 for an Epoch timestamp)."

On Linux, it looks like time.monotonic() is the number of seconds since Linux
boot, so the value is small and we may not loose precision because of the IEEE
754 format.

The following issue is a huge refactoring of the pytime.c file to support
nanosecond resolution:
http://bugs.python.org/issue22117

My patch for this issue is a work-in-progress (I have a partial patch to use a
64-bit integer type), but it will be done before Python 3.5 release.

I prefer to first push monotonic clocks everywhere, and then support nanosecond.

http://bugs.python.org/review/22043/diff/12788/Python/pytime.c
File Python/pytime.c (right):

http://bugs.python.org/review/22043/diff/12788/Python/pytime.c#newcode129
Python/pytime.c:129: static int has_getickcount64 = -1;
On 2014/08/31 02:24:18, AntoinePitrou wrote:
> You should fix the typo in the variable name.

Oh, I just moved the code from timemodule.c. But ok, I fixed the typo.

http://bugs.python.org/review/22043/diff/12788/Python/pytime.c#newcode141
Python/pytime.c:141: has_getickcount64 = (Py_GetTickCount64 != NULL);
On 2014/08/31 02:24:18, AntoinePitrou wrote:
> Is it expected to fail?

MSDN documentation says that GetTickCount64() is available since Windows Vista
(6.0) and Windows Server 2008 (6.0).

So GetTickCount64() must be present in this case.

I replaced the test with an assertion.

http://bugs.python.org/review/22043/diff/12788/Python/pytime.c#newcode233
Python/pytime.c:233: return -1;
On 2014/08/31 02:24:18, AntoinePitrou wrote:
> The doc in pytime.h says that "the function never fails".

_PyTime_monotonic() never fails, _PyTime_monotonic_info() can fail. That's why
_PyTime_monotonic() contains an assertion and its return type is "void".

My expectation is that clock_gettime(CLOCK_MONOTONIC) always work or always
fail. See clock_gettime() documentation: it returns EINVAL if CLOCK_MONOTONIC is
not supported on the system. I don't see why the behaviour would change between
two cals.
Sign in to reply to this message.

RSS Feeds Recent Issues | This issue
This is Rietveld 894c83f36cb7