Repository navigation
methods decorated with compute and launched in separate process can't be interrupted #1
Description
Activity
- added 2 commits that reference this issue
on Sep 4, 2026 - added 4 commits that reference this issue
on Sep 17, 2026 Current-API review (2026-10-06): keep this issue open. The legacy
@dryml.computeAPI is superseded, and Execute-backeddispatch.runnow handles notebookKeyboardInterrupt: it tries confirmed pre-GO cancellation, otherwise requests post-GO cancellation, then re-raises without waiting in the shell (merged PR #53,8161e8a84b4e90d13a7172c0ecaaa1f40b3fb5ce;src/dryml/dispatch/api.py:299-317). A real-kernel test intests/dispatch/test_notebook.pyverifies the shell/task remain usable after interruption, but allows either interrupt delivery or normal completion; a request is not proof that a worker stopped.Remaining gap: generic
dryml.execute.Executor.run()and CoreExecutor.run()still callsubmit(...).result()without requesting cancellation on Ctrl-C (src/dryml/execute/executor.py:312-372,src/dryml/core/execute.py:2592-2652). Their one-offrun()helpers attempt cleanup after a caught interrupt without first cancelling nonterminal work (src/dryml/execute/executor.py:1408-1431,src/dryml/core/execute.py:3012-3035). Thus the old observable symptom is still reachable through these supported direct Execute APIs;close(cancel=False)can wait for ongoing work. Post-GO stop must remain best-effort and report cancellation only after owned-process/group termination is confirmed, as existing backend tests require.Suggested fix: bring the Dispatch pre-GO-cancel/post-GO-request sequence to both blocking generic/Core run surfaces and leave cleanup with the owned future until terminality. Test blocking Ctrl-C, late worker termination, retained recovery handle, and subprocess/Windows semantics. This does not require claiming signal delivery directly to the worker, killing escaped descendants, or native Windows Ray support.
Encountered when running dryml code in a jupyter notebook.
I decorated a training method with @dryml.compute and realized I had included debug print statements in a
forwardmethod of a pytorch model (which is called very frequently) and the cell output was being flooded with messages. I interrupted the cell, but realized that the subprocess doesn't receive the interrupt signal, and in fact won't stop because it waits for the closing signal from one of the queues. I had to terminate the process.Could be more reason to go to ray for this type of execution?