diff options
| author | Victor Stinner <vstinner@python.org> | 2021-09-30 08:16:51 (GMT) |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-09-30 08:16:51 (GMT) |
| commit | 37b8294d6295ca12553fd7c98778be71d24f4b24 (patch) | |
| tree | 8d9d17fb410224326246dbb25d762feb9aae6053 /Include/cpython | |
| parent | a1437170039dc2c07e6040d3a8ba8d91434b730d (diff) | |
| download | cpython-37b8294d6295ca12553fd7c98778be71d24f4b24.zip cpython-37b8294d6295ca12553fd7c98778be71d24f4b24.tar.gz cpython-37b8294d6295ca12553fd7c98778be71d24f4b24.tar.bz2 | |
bpo-41710: PyThread_acquire_lock_timed() clamps the timout (GH-28643)
PyThread_acquire_lock_timed() now clamps the timeout into the
[_PyTime_MIN; _PyTime_MAX] range (_PyTime_t type) if it is too large,
rather than calling Py_FatalError() which aborts the process.
PyThread_acquire_lock_timed() no longer uses
MICROSECONDS_TO_TIMESPEC() to compute sem_timedwait() argument, but
_PyTime_GetSystemClock() and _PyTime_AsTimespec_truncate().
Fix _thread.TIMEOUT_MAX value on Windows: the maximum timeout is
0x7FFFFFFF milliseconds (around 24.9 days), not 0xFFFFFFFF
milliseconds (around 49.7 days).
Set PY_TIMEOUT_MAX to 0x7FFFFFFF milliseconds, rather than 0xFFFFFFFF
milliseconds.
Fix PY_TIMEOUT_MAX overflow test: replace (us >= PY_TIMEOUT_MAX) with
(us > PY_TIMEOUT_MAX).
Diffstat (limited to 'Include/cpython')
| -rw-r--r-- | Include/cpython/pytime.h | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/Include/cpython/pytime.h b/Include/cpython/pytime.h index b5a3513..db3adfa 100644 --- a/Include/cpython/pytime.h +++ b/Include/cpython/pytime.h @@ -14,7 +14,9 @@ extern "C" { store a duration, and so indirectly a date (related to another date, like UNIX epoch). */ typedef int64_t _PyTime_t; +// _PyTime_MIN nanoseconds is around -292.3 years #define _PyTime_MIN INT64_MIN +// _PyTime_MAX nanoseconds is around +292.3 years #define _PyTime_MAX INT64_MAX #define _SIZEOF_PYTIME_T 8 |