| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(GH-111111) (GH-111172)
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 6c23635f2b7067ef091a550954e09f8b7c329e3f)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: James Hilton-Balfe <gobot1234yt@gmail.com>
|
| |
|
|
|
| |
(cherry picked from commit e94edab727d07bef851e0e1a345e18a453be863d)
Co-authored-by: JosephSBoyle <48555120+JosephSBoyle@users.noreply.github.com>
|
| |
|
|
|
|
|
|
| |
after raising ExceptionGroup (GH-98544) (#98550)
GH-98543: Fix `asyncio.TaskGroup` to not keep reference to errors after raising ExceptionGroup (GH-98544)
(cherry picked from commit f4a14941e6e54b15012fca067f6a9b2ff29f201a)
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.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 f51f54f39d384da63be622bcdc9cf4cfb43bad3d)
Co-authored-by: Guido van Rossum <guido@python.org>
|
| |
|
|
|
| |
(cherry picked from commit 7da4937748eb588bb0e977839061ce76cab1b252)
Co-authored-by: Yury Selivanov <yury@edgedb.com>
|
| |
|
|
|
|
|
|
| |
(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>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
(GH-31837)
|
| |
|
| |
Now uses .cancel()/.uncancel(), for even fewer broken edge cases.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
