Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor cancellation system to eagerly propagate effective state #958

Merged
merged 5 commits into from May 6, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
18 changes: 1 addition & 17 deletions docs/source/reference-core.rst
Expand Up @@ -514,23 +514,7 @@ objects.
exception, and (2) this scope is the one that was responsible
for triggering this :exc:`~trio.Cancelled` exception.

.. attribute:: cancel_called

Readonly :class:`bool`. Records whether cancellation has been
requested for this scope, either by an explicit call to
:meth:`cancel` or by the deadline expiring.

This attribute being True does *not* necessarily mean that the
code within the scope has been, or will be, affected by the
cancellation. For example, if :meth:`cancel` was called after
the last checkpoint in the ``with`` block, when it's too late to
deliver a :exc:`~trio.Cancelled` exception, then this attribute
will still be True.

This attribute is mostly useful for debugging and introspection.
If you want to know whether or not a chunk of code was actually
cancelled, then :attr:`cancelled_caught` is usually more
appropriate.
.. autoattribute:: cancel_called


Trio also provides several convenience functions for the common
Expand Down
4 changes: 4 additions & 0 deletions newsfragments/58.misc.rst
@@ -0,0 +1,4 @@
The plumbing of Trio's cancellation system has been substantially overhauled
to improve performance and ease future planned improvements. Notably, there is
no longer any internal concept of a "cancel stack", and checkpoints now take
constant time regardless of the cancel scope nesting depth.
5 changes: 5 additions & 0 deletions newsfragments/958.bugfix.rst
@@ -0,0 +1,5 @@
Inspecting the :attr:`~trio.CancelScope.cancel_called` attribute of a
not-yet-exited cancel scope whose deadline is in the past now always
returns ``True``, like you might expect. (Previously it would return
``False`` for not-yet-entered cancel scopes, and for active cancel
scopes until the first checkpoint after their deadline expiry.)