Signed-off-by: Christoph Hamsen <hamsen.christoph@posteo.de>
Co-authored-by: July Tikhonov <july.tikh@gmail.com>
(cherry picked from commit c9ed0327a9)
Co-authored-by: Christoph Hamsen <37963496+xopham@users.noreply.github.com>
Reason: we were too hasty in deprecating this.
We shouldn't deprecate it before we have a replacement.
(cherry picked from commit 09de8d7aaf)
Co-authored-by: Guido van Rossum <guido@python.org>
Check for None when iterating over `self._pipes.values()`.
(cherry picked from commit e2e6b95c03)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
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.
(cherry picked from commit 3a49dbb98c)
Co-authored-by: hetmankp <728670+hetmankp@users.noreply.github.com>
* When chaining futures, skip callback if loop closed.
* When shutting down an executor, don't wake a closed loop.
(cherry picked from commit e9d63760fe)
Co-authored-by: Guido van Rossum <guido@python.org>
The main problem was that an unluckily timed task cancellation could cause
the semaphore to be stuck. There were also doubts about strict FIFO ordering
of tasks allowed to pass.
The Semaphore implementation was rewritten to be more similar to Lock.
Many tests for edge cases (including cancellation) were added.
(cherry picked from commit 24e0379624)
Co-authored-by: Cyker Way <cykerway@gmail.com>
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
(cherry picked from commit 6281affee6)
Co-authored-by: Hendrik Makait <hendrik.makait@gmail.com>
When a task catches CancelledError and raises some other error,
the other error should not silently be suppressed.
Any scenario where a task crashes in cleanup upon cancellation
will now result in an ExceptionGroup wrapping the crash(es)
instead of propagating CancelledError and ignoring the side errors.
NOTE: This represents a change in behavior (hence the need to
change several tests). But it is only an edge case.
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
(cherry picked from commit f51f54f39d)
Co-authored-by: Guido van Rossum <guido@python.org>
Once the task group is shutting down, it should not be possible to create a new task.
Here "shutting down" means `self._aborting` is set, indicating that at least one task
has failed and we have cancelled all others.
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
(cherry picked from commit 594c369949)
Co-authored-by: Guido van Rossum <guido@python.org>
Fix#91487
When transferring a small file, e.g. 256 KiB, the speed of this PR is comparable. However, if a large file, e.g. 65536 KiB, is transferred, asyncio UDP will be over 100 times faster than the original. The speed is presumably significantly faster if a larger file is transferred, e.g. 1048576 KiB.
Automerge-Triggered-By: GH:gpshead
The existing event loop `start_tls()` method is not sufficient for
connections using the streams API. The existing StreamReader works
because the new transport passes received data to the original protocol.
The StreamWriter must then write data to the new transport, and the
StreamReaderProtocol must be updated to close the new transport
correctly.
The new StreamWriter `start_tls()` updates itself and the reader
protocol to the new SSL transport.
Co-authored-by: Ian Good <icgood@gmail.com>
After a long deliberation we ended up feeling that the message argument for Future.cancel(), added in 3.9, was a bad idea, so we're deprecating it in 3.11 and plan to remove it in 3.13.
Example:
async with asyncio.timeout(5):
await some_task()
Will interrupt the await and raise TimeoutError if some_task() takes longer than 5 seconds.
Co-authored-by: Guido van Rossum <guido@python.org>
Also from the _asyncio C accelerator module,
and adjust one test that the change caused to fail.
For more discussion see the discussion starting here:
https://github.com/python/cpython/pull/31394#issuecomment-1053545331
(Basically, @asvetlov proposed to return False from cancel()
when there is already a pending cancellation, and I went along,
even though it wasn't necessary for the task group implementation,
and @agronholm has come up with a counterexample that fails
because of this change. So now I'm changing it back to the old
semantics (but still bumping the counter) until we can have a
proper discussion about this.)
