| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
(GH-96724)
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
(cherry picked from commit 6281affee6423296893b509cd78dc563ca58b196)
Co-authored-by: Hendrik Makait <hendrik.makait@gmail.com>
|
|
|
|
|
|
|
|
|
| |
(#96395)
(cherry picked from commit e5b2453e61ba5376831093236d598ef5f9f1de61)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
| |
(GH-96323) (#96344)
(cherry picked from commit e860e521ec0d84e175269aeb15cf24bd6053ad17)
Co-authored-by: Kirill <iam@python273.pw>
Co-authored-by: Kirill <iam@python273.pw>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 f51f54f39d384da63be622bcdc9cf4cfb43bad3d)
Co-authored-by: Guido van Rossum <guido@python.org>
|
|
|
|
|
|
|
|
| |
(#96003)
(cherry picked from commit 914f6367a0d015986dafa7a9d542e24192753b6b)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
|
| |
(cherry picked from commit 7da4937748eb588bb0e977839061ce76cab1b252)
Co-authored-by: Yury Selivanov <yury@edgedb.com>
|
|
|
|
|
|
|
|
| |
(GH-32197)" (GH-95442) (GH-95652)
This reverts commit d4bb38f82bf18b00db3129031ce4969b6f0caab9.
(cherry picked from commit 0342c93a6b866118c894c4e1120fb4db316adebb)
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
|
|
|
|
|
|
|
|
| |
(GH-95602)
Co-authored-by: Guido van Rossum <guido@python.org>
(cherry picked from commit 2fef27589e44c91042c2598b5cad6c6ad0516d93)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
|
|
|
|
| |
(GH-95387)
(cherry picked from commit 54f48844d18bc6fb98849f15a2fc08f92ad240ea)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
|
|
|
|
|
|
|
|
| |
already expired are deliverered promptly (GH-95109) (GH-95216)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
(cherry picked from commit 0c6f898005099be189ee65bcfda659f5fc13b802)
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
|
|
|
|
|
| |
raised multiple times (GH-30274) (#94747)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
|
|
|
| |
(GH-94593)
(cherry picked from commit 14fea6b4d25658bc00adbb97dd40ea3d3e6843ad)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
| |
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 594c3699492bfb007650538726d953cbed55de04)
Co-authored-by: Guido van Rossum <guido@python.org>
|
|
|
|
|
|
|
|
|
| |
(GH-93299) (#93305)
(cherry picked from commit e6a57678cafe18ca132ee9510252168fcc392a8d)
Co-authored-by: Yury Selivanov <yury@edgedb.com>
Co-authored-by: Yury Selivanov <yury@edgedb.com>
|
|
|
|
|
| |
(cherry picked from commit 33880b4b1c60f54aa9e7fa02698a3c82eafe3dc7)
Co-authored-by: Oleg Iarygin <oleg@arhadthedev.net>
|
|
|
|
|
| |
https://github.com/python/cpython/issues/91880#issuecomment-1113914241 - With thanks to @MojoVampire for spotting this.
Automerge-Triggered-By: GH:gvanrossum
|
| |
|
|
|
|
| |
Fixes gh-91880.
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
| |
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
|
| |
|
|
|
|
| |
Co-authored-by: Yury Selivanov <yury@edgedb.com>
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
|
|
|
| |
Co-authored-by: Zachary Ware <zach@python.org>
|
|
|
|
|
| |
Task.cancel() (GH-31840)
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.
|
|
|
| |
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
| |
Co-authored-by: Yury Selivanov <yury@edgedb.com>
|
| |
|
| |
|
| |
|
|
|
|
| |
(GH-31837)
|
| |
|
|
|
|
|
| |
implementations (GH-31838)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
This change aligns the documentation at https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.Server
with the actual implementation
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
| |
Now uses .cancel()/.uncancel(), for even fewer broken edge cases.
|
|
|
|
|
| |
This changes cancelling() and uncancel() to return the count of pending cancellations.
This can be used to avoid bugs in certain edge cases (e.g. two timeouts going off at the same time).
|
|
|
|
| |
(#31512)
|
|
|
|
|
| |
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
|
|
|
|
|
|
| |
awaiter (GH-31383)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
|
| |
|
|
|
|
| |
(GH-31442)
|
|
|
| |
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Remove task group names (for now)
We're not sure that they are needed, and once in the code
we would never be able to get rid of them.
Yury wrote:
> Ideally, there should be a way for someone to build a "trace"
> of taskgroups/task leading to the current running task.
> We could do that using contextvars, but I'm not sure we should
> do that in 3.11.
* Pass optional name on to task in create_task()
* Remove a bunch of unused stuff
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
asyncio/taskgroups.py is an adaptation of taskgroup.py from EdgeDb, with the following key changes:
- Allow creating new tasks as long as the last task hasn't finished
- Raise [Base]ExceptionGroup (directly) rather than TaskGroupError deriving from MultiError
- Instead of monkey-patching the parent task's cancel() method,
add a new public API to Task
The Task class has a new internal flag, `_cancel_requested`, which is set when `.cancel()` is called successfully. The `.cancelling()` method returns the value of this flag. Further `.cancel()` calls while this flag is set return False. To reset this flag, call `.uncancel()`.
Thus, a Task that catches and ignores `CancelledError` should call `.uncancel()` if it wants to be cancellable again; until it does so, it is deemed to be busy with uninterruptible cleanup.
This new Task API helps solve the problem where TaskGroup needs to distinguish between whether the parent task being cancelled "from the outside" vs. "from inside".
Co-authored-by: Yury Selivanov <yury@edgedb.com>
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
|