GH- Improve asyncio.wait function
The original code creates the futures set two times.
We can create this set before, avoiding the second creation.
This new behaviour [breaks the aiokafka library](https://github.com/aio-libs/aiokafka/pull/672), because it gives an iterator to that function, so the second iteration become empty.
Automerge-Triggered-By: GH:1st1
(cherry picked from commit 7e5ef0a571)
Co-authored-by: Diogo Dutra <diogodutradamata@gmail.com>
The overflow occurs under some circumstances when a task or future
recursively returns itself.
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
(cherry picked from commit 42d873c63a)
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
Fix a race condition in the call_soon_threadsafe() method of
asyncio.ProactorEventLoop: do nothing if the self-pipe socket has
been closed.
(cherry picked from commit 1b0f0e3d7d)
Co-authored-by: Victor Stinner <vstinner@python.org>
* bpo-41696: Fix handling of debug mode in asyncio.run
This allows PYTHONASYNCIODEBUG or -X dev to enable asyncio debug mode
when using asyncio.run
* 📜🤖 Added by blurb_it.
Co-authored-by: hauntsaninja <>
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
(cherry picked from commit 0770ad948c)
Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
Stopping and restarting a proactor event loop on windows can lead to
spurious errors logged (ConnectionResetError while reading from the
self pipe). This fixes the issue by ensuring that we don't attempt
to start multiple copies of the self-pipe reading loop.
(cherry picked from commit ea5a6363c3)
Co-authored-by: Ben Darnell <ben@bendarnell.com>
Co-authored-by: Ben Darnell <ben@bendarnell.com>
Currently, if `asyncio.wait_for()` itself is cancelled it will always
raise `CancelledError` regardless if the underlying task is still
running. This is similar to a race with the timeout, which is handled
already.
(cherry picked from commit a2118a1462)
Co-authored-by: Elvis Pranskevichus <elvis@magic.io>
When I was fixing bpo-32751 back in GH-7216 I missed the case when
*timeout* is zero or negative. This takes care of that.
Props to @aaliddell for noticing the inconsistency.
(cherry picked from commit c517fc7121)
Co-authored-by: Elvis Pranskevichus <elvis@magic.io>
Fix grammar in BaseTransport.close docstring.
https://bugs.python.org/issue41572
Signed-off-by: Cleber Rosa <crosa@redhat.com>
(cherry picked from commit 1afb42cfa8)
Co-authored-by: Cleber Rosa <cleber.gnu@gmail.com>
asyncio.AbstractEventLoop.run_in_executor should be a method that returns an asyncio Future, not an async method.
This matches the concrete implementations, and the documentation better.
(cherry picked from commit 29f84294d8)
Co-authored-by: James Weaver <james.barrett@bbc.co.uk>
On Windows, fix asyncio recv_into() return value when the socket/pipe
is closed (BrokenPipeError): return 0 rather than an empty byte
string (b'').
(cherry picked from commit 602a971a2a)
Co-authored-by: Victor Stinner <vstinner@python.org>
These changes updates the doc to comprehensively mention the behaviour of gather.cancel()
Automerge-Triggered-By: @asvetlov
(cherry picked from commit d42528a3a2)
Co-authored-by: Vinay Sharma <vinay04sharma@icloud.com>
When I wrote the documentation for `asyncio.to_thread()`, I mistakenly assumed that `return await loop.run_in_executor(...)` within an async def function would return a Future. In reality, it returns a coroutine.
This likely won't affect typical usage of `asyncio.to_thread()`, but it's important for the documentation to be correct here. In general, we also tend to avoid returning futures from high-level APIs in asyncio.
(cherry picked from commit 2b201369b4)
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
Allows contextvars from the main thread to be accessed in the separate thread used in `asyncio.to_thread()`. See the [discussion](https://github.com/python/cpython/pull/20143GH-discussion_r427808225) in GH-20143 for context.
Automerge-Triggered-By: @aeros
(cherry picked from commit 0f56263e62)
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
Implements `asyncio.to_thread`, a coroutine for asynchronously running IO-bound functions in a separate thread without blocking the event loop. See the discussion starting from [here](https://github.com/python/cpython/pull/18410GH-issuecomment-628930973) in GH-18410 for context.
Automerge-Triggered-By: @aeros
(cherry picked from commit cc2bbc2227)
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
When an asyncio.Task is cancelled, the exception traceback now
starts with where the task was first interrupted. Previously,
the traceback only had "depth one."
Currently, if asyncio.wait_for() timeout expires, it cancels
inner future and then always raises TimeoutError. In case
those future is task, it can handle cancelation mannually,
and those process can lead to some other exception. Current
implementation silently loses thoses exception.
To resolve this, wait_for will check was the cancelation
successfull or not. In case there was exception, wait_for
will reraise it.
Co-authored-by: Roman Skurikhin <roman.skurikhin@cruxlab.com>
Motivation for this PR (comment from @vstinner in bpo issue):
```
Warning seen o AMD64 Ubuntu Shared 3.x buildbot:
https://buildbot.python.org/all/#/builders/141/builds/2593
test_devnull_output (test.test_a=syncio.test_subprocess.SubprocessThreadedWatcherTests) ...
Warning -- threading_cleanup() failed to cleanup 1 threads (count: 1, dangling: 2)
```
The following implementation details for the new method are TBD:
1) Public vs private
2) Inclusion in `close()`
3) Name
4) Coroutine vs subroutine method
5) *timeout* parameter
If it's a private method, 3, 4, and 5 are significantly less important.
I started with the most minimal implementation that fixes the dangling threads without modifying the regression tests, which I think is particularly important. I typically try to avoid directly modifying existing tests as much as possible unless it's necessary to do so. However, I am open to changing any part of this.
https://bugs.python.org/issue38356
If waitpid() is called elsewhere, waitpid() call fails with
ChildProcessError: use return code 255 in this case, and log a
warning. It ensure that the pidfd file descriptor is closed if this
error occurs.
Capturing exceptions into names can lead to reference cycles though the __traceback__ attribute of the exceptions in some obscure cases that have been reported previously and fixed individually. As these variables are not used anyway, we can remove the binding to reduce the chances of creating reference cycles.
See for example GH-13135
