Fix anyio patch: skip done tasks to prevent zombie-scope hot-loop#3
Open
constkolesnyak wants to merge 1 commit into
Open
Fix anyio patch: skip done tasks to prevent zombie-scope hot-loop#3constkolesnyak wants to merge 1 commit into
constkolesnyak wants to merge 1 commit into
Conversation
Third iteration of the anyio _deliver_cancellation spin. This time a CancelScope retained already-finished tasks in self._tasks (anyio doesn't always prune them before the cancel callback fires). For a done task _must_cancel=False (cleared on final step), _task_started is True, _fut_waiter is None — so the previous patch fell into the "waiter not done → cancel()" branch. task.cancel() is a no-op on done tasks, but should_retry was flagged anyway, so call_soon kept re-queuing forever. Observed live: three zombie-scopes in one process producing ~55k epoll_pwait/sec combined, 100% CPU on MainThread, load 1.6, 60°C. Confirmed via py-spy (stack parked on lines 91/95/97/98 of the patch) and a gc-scan dump of CancelScope objects (three active _cancel_handle scopes, each with a single done=True task). Fix: add `if task.done(): continue` at the top of the loop. Also add regression test that reproduces the zombie-scope shape with a stubbed done task and asserts no cancel() call, no retry, and no pending _cancel_handle.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Third iteration of the anyio
_deliver_cancellationhot-loop. Previous patches (ec0f8f7,f1d6329) covered the "only task is current" and "task has_must_cancel" cases. This one was caused by done tasks lingering inCancelScope._tasks— anyio 4.13.0 doesn't always prune them before the cancel callback fires.For a done task:
_must_cancel=False(cleared on final step),_task_started()=True,_fut_waiter=None. The previous patch fell into the "waiter not done → cancel()" branch, calledtask.cancel()(no-op on done tasks), and still flaggedshould_retry=True→ infinitecall_soon.Observed live
py-spy dump(stack parked on lines 91/95/97/98 of_anyio_patch.py) and a gc-scan ofCancelScopeobjects (each stuck scope had exactly onedone=Truetask)Changes
nerve/_anyio_patch.py: addif task.done(): continueat the top of the cancellation loop; updated module docstring with the third regression historytests/test_anyio_patch.py: new regression testtest_no_hot_loop_when_only_task_is_donereproducing the zombie-scope shape with a stubbed done task (asserts nocancel()call,should_retry=False,_cancel_handle=None); existing_FakeTaskupdated with adone()methodVerification
🤖 Generated with Claude Code