From cfb36f81f0d13fc5ea542f61002d7a9c7af71746 Mon Sep 17 00:00:00 2001 From: Jiong Gong Date: Thu, 24 Sep 2026 02:45:13 +0000 Subject: [PATCH] compass(runner): the exit bullet points at the refusal comment instead of restating its losses The package docstring's `exit` bullet said a hole at exit leaves "the graphs and five KV tensors it deletes" held. This runner allocates neither: `NonAllocatingRunner.allocate_kv_cache` records a block count and allocates nothing, and `capture_cudagraph` captures nothing, while ATOM creates `self.graphs` only inside its own `capture_cudagraph`. The comment on the `RPC_SURFACE` check in `model_runner` already says the opposite, and a test holds it against `ModelRunner.exit`'s body. The bullet was a second, unpinned copy of that loss list, and it had drifted. The bullet now names the dispatch site, says `ModelRunner.exit` is never reached, and points at that comment for what is lost. The sentence about the loop still breaking is unchanged. Closes #398 Co-Authored-By: Claude Opus 5.5 (1M context) --- atom/compass/runner/__init__.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/atom/compass/runner/__init__.py b/atom/compass/runner/__init__.py index 7fb76d831d..afc371f7e1 100644 --- a/atom/compass/runner/__init__.py +++ b/atom/compass/runner/__init__.py @@ -29,9 +29,9 @@ class is checked against `overrides.RPC_SURFACE`, the table of names a worker the table marks unwaited, a hole parks nobody, and what is lost is the work the name stood for: -- `exit` (`engine_core.py:260`) never reaches `ModelRunner.exit`, so the - distributed environment is never destroyed and the graphs and five KV tensors - it deletes stay held. The worker still leaves its loop -- `busy_loop` breaks +- `exit` (`engine_core.py:260`) never reaches `ModelRunner.exit`; the comment + on the `RPC_SURFACE` check in `model_runner` says what that loses here. + The worker still leaves its loop -- `busy_loop` breaks on the dispatched name, in a statement beside the per-runner loop rather than inside it -- so the symptom is what shutdown failed to release, not a hang. - `process_kvconnector_output` never starts the asynchronous KV load its