Process shell messages concurrently while async cells await#24
Closed
ncoop57 wants to merge 1 commit into
Closed
Conversation
Subshells handled mailbox items strictly one at a time, so an execute_request sent while an async cell was awaiting could not run until that cell finished. solveit's load_dialog depends on this re-entrancy (a cell awaits a server roundtrip that sends executes back to the same kernel), so it deadlocked until the client timeout. Each shell message now runs in its own task on the subshell loop. Sync cells never suspend, so they still run strictly in order, and stop_on_error aborting is checked in each task's first synchronous step. Execution state uses a counter, cancel scopes are tracked per execution (interrupt cancels all awaiting cells), and pending tasks are cancelled on subshell shutdown. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
Fixed in microio (I think!) |
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
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.
Issue
solveit's
load_dialogtimes out (240s) with ipymini whenever the loaded dialog has code messages. The call is re-entrant: a code cell awaits an HTTP roundtrip to the solveit server, and the server'simport_codesends execute_requests back to the same kernel before responding. Subshells handled mailbox items strictly one at a time, so those requests sat queued behind the awaiting cell forever — a deadlock. (ipyku_launcheravoids this by nulling ipykernel's_main_asyncio_lock; stockipykernel_launcherdeadlocks the same way ipymini did.)Fix
Subshell._handle_actor_itemnow spawns each shell message as a task on the subshell loop instead of awaiting it inline, so the mailbox keeps draining while an async cell awaits. Sync cells never suspend, so they still run strictly in order, and the stop_on_error abort check runs in each task's first synchronous step. Supporting changes:executingonly flip when no execute is active.Semantic change
An erroring async cell no longer aborts executes submitted while it was awaiting — they may already have run. This matches
ipyku_launcher(solveit's current default).test_subshell_stop_on_error_isolatednow uses a sync failing cell, preserving its intent (cross-subshell abort isolation).Testing
tests/kernel/test_concurrent_execute.py: reproduces the deadlock (red before this change) and asserts sync cells still serialize.meta/notebook test needs an uncommitted local file, unrelated).SolveitKernelManager/ConKernelClientwithIPY_LAUNCHER=ipymini: theimport_codepattern completes in ~0.5s; the same script on main reproduces theTimeoutError.🤖 Generated with Claude Code