mirror of
https://github.com/python/cpython.git
synced 2025-10-07 07:31:46 +00:00
d8948c5e09
Currently, asyncio.wait_for(fut), upon reaching the timeout deadline,
cancels the future and returns immediately. This is problematic for
when *fut* is a Task, because it will be left running for an arbitrary
amount of time. This behavior is iself surprising and may lead to
related bugs such as the one described in bpo-33638:
condition = asyncio.Condition()
async with condition:
await asyncio.wait_for(condition.wait(), timeout=0.5)
Currently, instead of raising a TimeoutError, the above code will fail
with `RuntimeError: cannot wait on un-acquired lock`, because
`__aexit__` is reached _before_ `condition.wait()` finishes its
cancellation and re-acquires the condition lock.
To resolve this, make `wait_for` await for the task cancellation.
The tradeoff here is that the `timeout` promise may be broken if the
task decides to handle its cancellation in a slow way. This represents
a behavior change and should probably not be back-patched to 3.6 and
earlier.
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| __init__.py | ||
| base_events.py | ||
| base_futures.py | ||
| base_subprocess.py | ||
| base_tasks.py | ||
| constants.py | ||
| coroutines.py | ||
| events.py | ||
| format_helpers.py | ||
| futures.py | ||
| locks.py | ||
| log.py | ||
| proactor_events.py | ||
| protocols.py | ||
| queues.py | ||
| runners.py | ||
| selector_events.py | ||
| sslproto.py | ||
| streams.py | ||
| subprocess.py | ||
| tasks.py | ||
| transports.py | ||
| unix_events.py | ||
| windows_events.py | ||
| windows_utils.py | ||