| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
(#111983)
Issue a ResourceWarning instead.
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
|
|
|
|
|
| |
Try to clean up the socket file we create so we don't add unused noise to the file system.
|
|
|
|
|
| |
(#111601)
Call loop exception handler for exceptions in `client_connected_cb` of `asyncio.start_server` so that applications can handle it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
|
|
|
|
| |
- `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`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
Co-authored-by: James Hilton-Balfe <gobot1234yt@gmail.com>
|
|
|
|
|
| |
reference (#111017)
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
|
| |
|
|
|
| |
Effectively introduce an unstable, private (really: protected) API for subclasses that want to override `run_forever()`.
|
|
|
| |
This is needed to pave the way for deprecating and eventually killing the event loop policy system (which is over-engineered and rarely used).
|
| |
|
|
|
| |
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
|
| |
|
| |
|
|
|
|
|
|
| |
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().
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 282edd7b2a74c4dfe1bfe3c5b1d30f9c21d554d6.
_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.
Co-authored-by: Davide Rizzo <sorcio@gmail.com>
|
| |
|
| |
|
|
|
|
| |
(#107650)
|
| |
|
| |
|
| |
|
|
|
|
| |
close(). (#106504)
|
|
|
| |
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
| |
method (#105685)
|
|
|
|
| |
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
| |
(#104586)
|
| |
|
|
|
|
| |
Instead, add docstring to create_eager_task_factory.
|
|
|
|
| |
eagerly (#104138)
|
|
|
|
|
| |
eagerly (#104140)
Co-authored-by: Carl Meyer <carl@oddbird.net>
|
|
|
|
| |
Co-authored-by: Jacob Bower <jbower@meta.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
`asyncio`. (#17425)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
| |
data is still pending (#103463)
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
(#102811)
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
|
|
|
|
|
| |
`asyncio.iscoroutine` (#102749)
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
|
| |
|
| |
|
|
|
|
| |
(#102398)
|
| |
|
|
|
| |
Changes `asyncio.wait_for` to use `asyncio.timeout` as its underlying implementation.
|
|
|
|
|
| |
`asyncio.StreamWriter.start_tls` (#101335)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
|
| |
`asyncio.base_events.BaseEventLoop._add_callback` (#101197)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.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.open_connection` (#100615)
|
|
|
|
|
| |
asyncio (#31871)
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
|
|
|
| |
Co-authored-by: pranavtbhat
|