gh-111347: Remove wrong assertion in test_sendfile (GH-111377)
Windows is different.
(cherry picked from commit fa35b9e89b)
Co-authored-by: zcxsythenew <30565051+zcxsythenew@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>
- `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-110695: test_asyncio uses 50 ms for clock resolution (GH-110952)
Before utils.CLOCK_RES constant was added (20 ms), test_asyncio
already used 50 ms.
(cherry picked from commit 9a9fba825f)
Co-authored-by: Victor Stinner <vstinner@python.org>
gh-110335: asyncio test_unix_events cleans multiprocessing (GH-110336)
test_unix_events tests using the multiprocessing module now call
multiprocessing.util._cleanup_tests().
(cherry picked from commit 1337765225)
Co-authored-by: Victor Stinner <vstinner@python.org>
gh-110088, gh-109878: Fix test_asyncio timeouts (#110092)
Fix test_asyncio timeouts: don't measure the maximum duration, a test
should not measure a CI performance. Only measure the minimum
duration when a task has a timeout or delay. Add CLOCK_RES to
test_asyncio.utils.
(cherry picked from commit db0a258e79)
gh-110088: Fix asyncio test_prompt_cancellation() (GH-110157)
Don't measure the CI performance: don't test the maximum elapsed
time. The check failed on a slow CI.
(cherry picked from commit c62b49ecc8)
Co-authored-by: Victor Stinner <vstinner@python.org>
gh-109833: Fix asyncio test_wait_for() (GH-109834)
Expect the test to be "short" but don't measure the exact performance
of the CI. SHORT_TIMEOUT is about 30 seconds whereas the cancelled
coroutine takes around 1 hour.
(cherry picked from commit f29bc9c9a0)
Co-authored-by: Victor Stinner <vstinner@python.org>
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-109582: test_fork_signal_handling should wait for event (GH-109605)
Sometimes the child_handled event was missing because either
the child quits before it gets a chance to handle the signal,
or the parent asserts before the event notification is
delivered via IPC. Synchronize explicitly to avoid this.
(cherry picked from commit 608c1f3083)
Co-authored-by: Davide Rizzo <sorcio@gmail.com>
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>
gh-109295: Clean up multiprocessing in test_asyncio and test_compileall (GH-109298)
test_asyncio and test_compileall now clean up multiprocessing by
calling multiprocessing _cleanup_tests(): explicitly clean up
resources and stop background processes like the resource tracker.
(cherry picked from commit 09ea4b8706)
Co-authored-by: Victor Stinner <vstinner@python.org>
gh-107895: Fix test_asyncio.test_runners when run it in CPython's "development mode" (GH-108168)
(cherry picked from commit 014a5b71e7)
Co-authored-by: Joon Hwan 김준환 <xncbf12@gmail.com>
The default task name is "Task-<counter>" (if no name is passed in during Task creation).
This is initialized in `Task.__init__` (C impl) using string formatting, which can be quite slow.
Actually using the task name in real world code is not very common, so this is wasted init.
Let's defer this string formatting to the first time the name is read (in `get_name` impl),
so we don't need to pay the string formatting cost if the task name is never read.
We don't change the order in which tasks are assigned numbers (if they are) --
the number is set on task creation, as a PyLong instead of a formatted string.
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
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>
This starts the process. Users who don't specify their own start method
and use the default on platforms where it is 'fork' will see a
DeprecationWarning upon multiprocessing.Pool() construction or upon
multiprocessing.Process.start() or concurrent.futures.ProcessPool use.
See the related issue and documentation within this change for details.
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>
