gh-124309: fix staggered race on eager tasks (GH-124847)
This patch is entirely by Thomas and Peter
(cherry picked from commit 979c0df7c0)
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
When an `StopIteration` raises into `asyncio.Future`, this will cause
a thread to hang. This commit address this by not raising an exception
and silently transforming the `StopIteration` with a `RuntimeError`,
which the caller can reconstruct from `fut.exception().__cause__`
(cherry picked from commit 4826d52338)
Co-authored-by: Jamie Phan <jamie@ordinarylab.dev>
gh-121913: Use str(exc) instead of exc.strerror in `asyncio.base_events` (GH-122269)
(cherry picked from commit 070f1e2e5b)
Co-authored-by: AN Long <aisk@users.noreply.github.com>
When wrapped, `_SSLProtocolTransport._force_close(exc)` is called just like in the unwrapped scenario `_SelectorTransport._force_close(exc)` or `_ProactorBasePipeTransport._force_close(exc)` would be called, except here the exception needs to be passed through the `SSLProtocol._abort()` method, which didn't accept an exception object.
This commit ensures that this path works, in the same way that the uvloop implementation of SSLProto passes on the exception (on which the current implementation of SSLProto is based).
(cherry picked from commit 1ff0238594)
Co-authored-by: Martijn Pieters <mj@zopatista.com>
* [3.12] gh-109538: Avoid RuntimeError when StreamWriter is deleted with closed loop (GH-111983)
Issue a ResourceWarning instead.
(cherry picked from commit e0f5127975)
gh-109538: Avoid RuntimeError when StreamWriter is deleted with closed loop (#111983)
Issue a ResourceWarning instead.
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
(cherry picked from commit e0f5127975)
* Fix missing warnings import
Call loop exception handler for exceptions in `client_connected_cb` of `asyncio.start_server` so that applications can handle it..
(cherry picked from commit 229f44d353)
gh-79033: Try to fix asyncio.Server.wait_closed() again (GH-111336)
* Try to fix asyncio.Server.wait_closed() again
I identified the condition that `wait_closed()` is intended
to wait for: the server is closed *and* there are no more
active connections.
When this condition first becomes true, `_wakeup()` is called
(either from `close()` or from `_detach()`) and it sets `_waiters`
to `None`. So we just check for `self._waiters is None`; if it's
not `None`, we know we have to wait, and do so.
A problem was that the new test introduced in 3.12 explicitly
tested that `wait_closed()` returns immediately when the server
is *not* closed but there are currently no active connections.
This was a mistake (probably a misunderstanding of the intended
semantics). I've fixed the test, and added a separate test that
checks exactly for this scenario.
I also fixed an oddity where in `_wakeup()` the result of the
waiter was set to the waiter itself. This result is not used
anywhere and I changed this to `None`, to avoid a GC cycle.
* Update Lib/asyncio/base_events.py
---------
(cherry picked from commit 2655369559)
Co-authored-by: Guido van Rossum <guido@python.org>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
- `ThreadedChildWatcher.close()` is now *officially* a no-op; `_join_threads()` never did anything.
- Threads created by that class are now named `asyncio-waitpid-NNN`.
- `test.test_asyncio.utils.TestCase.close_loop()` now waits for the child watcher's threads, but not forever; if a thread hangs, it raises `RuntimeError`.
(cherry picked from commit c3bb10c930)
Co-authored-by: Guido van Rossum <guido@python.org>
asyncio.TaskGroup and asyncio.Timeout classes now raise proper RuntimeError
if they are improperly used.
* When they are used without entering the context manager.
* When they are used after finishing.
* When the context manager is entered more than once (simultaneously or
sequentially).
* If there is no current task when entering the context manager.
They now remain in a consistent state after an exception is thrown,
so subsequent operations can be performed correctly (if they are allowed).
(cherry picked from commit 6c23635f2b)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: James Hilton-Balfe <gobot1234yt@gmail.com>
gh-109955 : Update state transition comments for asyncio.Task (GH-109910)
(cherry picked from commit 45cf5b0c69)
Co-authored-by: Kristján Valur Jónsson <sweskman@gmail.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Remove loop from docstring for asyncio.streams.open_connection (GH-108528)
(cherry picked from commit e721f7a951)
Co-authored-by: Tom Gillespie <tgbugs@gmail.com>
gh-109709: Fix asyncio test_stdin_broken_pipe() (GH-109710)
Replace harcoded sleep of 500 ms with synchronization using a pipe.
Fix also Process._feed_stdin(): catch also BrokenPipeError on
stdin.write(input), not only on stdin.drain().
(cherry picked from commit cbbdf2c144)
Co-authored-by: Victor Stinner <vstinner@python.org>
gh-108973: Fix asyncio test_subprocess_consistent_callbacks() (GH-109431)
SubprocessProtocol process_exited() method can be called before
pipe_data_received() and pipe_connection_lost() methods. Document it
and adapt the test for that.
Revert commit 282edd7b2a.
_child_watcher_callback() calls immediately _process_exited(): don't
add an additional delay with call_soon(). The reverted change didn't
make _process_exited() more determistic: it can still be called
before pipe_connection_lost() for example.
(cherry picked from commit ced6924630)
Co-authored-by: Victor Stinner <vstinner@python.org>
Co-authored-by: Davide Rizzo <sorcio@gmail.com>
subprocess's communicate(None) closes stdin of the child process, after
sending no (extra) data. Make asyncio variant do the same.
This fixes issues with processes that waits for EOF on stdin before
continuing.
Also use `raise TimeOut from <CancelledError instance>` so that the CancelledError is set
in the `__cause__` field rather than in the `__context__` field.
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
