Skip to content

Commit

Permalink
[docs] clarify checkpoint semantics for trio.open_nursery (#3011)
Browse files Browse the repository at this point in the history
* clarify checkpoint semantics for trio.open_nursery

* clarify what schedule-but-no-cancellation-point means for nurseries
  • Loading branch information
jakkdl committed Jun 14, 2024
1 parent 0f5fc6c commit 451393a
Show file tree
Hide file tree
Showing 2 changed files with 7 additions and 1 deletion.
2 changes: 2 additions & 0 deletions docs/source/reference-core.rst
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,8 @@ them. Here are the rules:
only that one will act as a checkpoint. This is documented
on a case-by-case basis.

* :func:`trio.open_nursery` is a further exception to this rule.

* Third-party async functions / iterators / context managers can act
as checkpoints; if you see ``await <something>`` or one of its
friends, then that *might* be a checkpoint. So to be safe, you
Expand Down
6 changes: 5 additions & 1 deletion src/trio/_core/_run.py
Original file line number Diff line number Diff line change
Expand Up @@ -986,7 +986,11 @@ def open_nursery(
new `Nursery`.
It does not block on entry; on exit it blocks until all child tasks
have exited.
have exited. If no child tasks are running on exit, it will insert a
schedule point (but no cancellation point) - equivalent to
:func:`trio.lowlevel.cancel_shielded_checkpoint`. This means a nursery
is never the source of a cancellation exception, it only propagates it
from sub-tasks.
Args:
strict_exception_groups (bool): Unless set to False, even a single raised exception
Expand Down

0 comments on commit 451393a

Please sign in to comment.