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>
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>
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>
Add BaseEventLoop.wait_executor_on_close attribute: true by default.
loop.close() now waits for the default executor to finish by default.
Set loop.wait_executor_on_close attribute to False to not wait for
the executor.
This will address the common mistake many asyncio users make:
an "except Exception" clause breaking Tasks cancellation.
In addition to this change, we stop inheriting asyncio.TimeoutError
and asyncio.InvalidStateError from their concurrent.futures.*
counterparts. There's no point for these exceptions to share the
inheritance chain.
In 3.9 we'll focus on implementing supervisors and cancel scopes,
which should allow better handling of all exceptions, including
SystemExit and KeyboardInterrupt
