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 /Modules/_threadmodule.c | |
| 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 'Modules/_threadmodule.c')
| -rw-r--r-- | Modules/_threadmodule.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/Modules/_threadmodule.c b/Modules/_threadmodule.c index 5b5d2c5..fa7e6d0 100644 --- a/Modules/_threadmodule.c +++ b/Modules/_threadmodule.c @@ -164,7 +164,7 @@ lock_acquire_parse_args(PyObject *args, PyObject *kwds, _PyTime_t microseconds; microseconds = _PyTime_AsMicroseconds(*timeout, _PyTime_ROUND_TIMEOUT); - if (microseconds >= PY_TIMEOUT_MAX) { + if (microseconds > PY_TIMEOUT_MAX) { PyErr_SetString(PyExc_OverflowError, "timeout value is too large"); return -1; |