Merge pull request #958 from oremanj/cancelstatus

Refactor cancellation system to eagerly propagate effective state

Author: njsmith

docs/source/reference-core.rst

@@ -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

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.

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.)