gh-118516: clarify that subprocess are automatically killed if transport gets garbage collected (GH-140997)
(cherry picked from commit 101c9c0a21)
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
gh-119711: describe `create_datagram_endpoint`'s behavior in asyncio when `local_addr` is `None` (GH-136913)
(cherry picked from commit 1481384141)
Co-authored-by: AN Long <aisk@users.noreply.github.com>
In 3.13.3 we accidentally broke the interface for custom task factory. Factory authors added workarounds.
This PR (for 3.13.4) unbreaks task factories that haven't made a workaround yet while also supporting those that have.
NOTE: The custom task factory API will change to what we accidentally released in 3.13.3.
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
gh-121333: Clarify what is the default executor for asyncio.run_in_executor (GH-121335)
(cherry picked from commit facf9862da)
Co-authored-by: AN Long <aisk@users.noreply.github.com>
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
These give applications the option of more forcefully terminating client
connections for asyncio servers. Useful when terminating a service and
there is limited time to wait for clients to finish up their work.
This is a do-over with a test fix for gh-114432, which was reverted.
These give applications the option of more forcefully terminating client
connections for asyncio servers. Useful when terminating a service and
there is limited time to wait for clients to finish up their work.
* 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
---------
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
Clarify the docs of asyncio.loop.subprocess_exec()
Clarify the documentation of stdin, stdout and stderr arguments of
asyncio.loop.subprocess_exec().
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
Partially revert changes made in GH-93453.
asyncio.DefaultEventLoopPolicy.get_event_loop() now emits a
DeprecationWarning and creates and sets a new event loop instead of
raising a RuntimeError if there is no current event loop set.
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
asyncio.get_event_loop() now always return either running event loop or
the result of get_event_loop_policy().get_event_loop() call. The latter
should now raise an RuntimeError if no current event loop was set
instead of creating and setting a new event loop.
It affects also a number of asyncio functions and constructors which
call get_event_loop() implicitly: ensure_future(), shield(), gather(),
etc.
DeprecationWarning is no longer emitted if there is no running event loop but
the current event loop was set.
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
