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>
Document the `port` parameter to `loop.create_server` in `asyncio`. In
particular, note that if `host` resolves to multiple network interfaces,
passing in `port=0` will result in a different random unused port being
used for each interface.
Automerge-Triggered-By: GH:ericvsmith
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>
Pierre Ossman (ThinLinc team)
Guido van Rossum
Serhiy Storchaka
beavailable
Nikita Sobolev
InSync
Thomas Grainger
Hadházy Tamás
Jack Nelson
Sam Bull
Rafael Fontenelle
July Tikhonov
Carol Willing
Jelle Zijlstra
Brian Skinn
Ben Darnell
Oleg Iarygin
Stanley
Kumar Aditya
C.A.M. Gerlach
zhanpon
Pamela Fox
Andrzej Bartosiński
Andrew Svetlov
Alex Grönholm
Paul Bryan
Rob
Jim Crist-Harif
Hugo van Kemenade
meowmeowmeowcat
Vinicius Gubiani Ferreira
Illia Volochii
Zac Bentley
Bruno