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-131325: fix sendfile fallback implementation to drain data after writing to transport (GH-131376)
(cherry picked from commit 94f4d87aeb)
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
gh-128916: Do not set `SO_REUSEPORT` on non-`AF_INET*` sockets (GH-128933)
* gh-128916: Do not set `SO_REUSEPORT` on non-`AF_INET*` sockets
Do not attempt to set ``SO_REUSEPORT`` on sockets of address familifies other
than ``AF_INET`` and ``AF_INET6``, as it is meaningless with these address
families, and the call with fail with Linux kernel 6.12.9 and newer.
* Apply suggestions from code review
---------
(cherry picked from commit 3829104ab4)
Co-authored-by: Michał Górny <mgorny@gentoo.org>
Co-authored-by: Vinay Sajip <vinay_sajip@yahoo.co.uk>
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>
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>
It was a no-op when used as recommended (after close()).
I had to debug one test (test__sock_sendfile_native_failure) --
the cleanup sequence for the test fixture was botched.
Hopefully that's not a portend of problems in user code --
this has never worked so people may well be doing this wrong. :-(
Co-authored-by: kumar aditya
Ensure that the event loop's `_thread_id` attribute and the asyncgen hooks set by `sys.set_asyncgen_hooks()` are always restored no matter where a KeyboardInterrupt exception is raised.
This parameter was accidentally removed when fixing
https://bugs.python.org/issue45129, this reverts the unnecessary changes
there.
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
Due to significant security concerns, the reuse_address parameter of
asyncio.loop.create_datagram_endpoint, deprecated in Python 3.9, is
now removed. This is because of the behavior of the socket option
SO_REUSEADDR in UDP.
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Thomas Grainger