Spyder IPython console Ctrl+C and Run‑command timeout: interaction and precedence

Short answer

The three cancellation paths in Spyder — Ctrl+C in the IPython console, the Stop toolbar button, and the Run-command execution timeout (Spyder 5.0+) — are independent triggers racing toward the same target. There is no documented priority arbitration between them. Whichever fires first ends the execution; the later one becomes a no-op because there is no longer a running cell to act on. So if you press Ctrl+C while a timeout is counting down, the interrupt wins by timing alone, and the timeout timer — which is tied to that run — is simply discarded. The timeout does not "abort" your Stop request, and Stop does not wait for the timeout.

What each mechanism actually does

They differ in how they terminate, which determines the kernel's end state:

• Ctrl+C delivers a KeyboardInterrupt into the running kernel (SIGINT on POSIX). It interrupts at the Python level, at the next bytecode opportunity. It does not kill the kernel process, and code blocked in C extensions, native I/O waits, or tight compiled loops may ignore it entirely.
• Stop button kills or restarts the kernel/subprocess. This is the forceful path — it terminates code that Ctrl+C cannot reach, but the kernel namespace is fully reset.
• Run timeout is enforced by Spyder's execution machinery watching elapsed time. When it fires it terminates the run, which is functionally closer to the Stop path than to a KeyboardInterrupt.

Kernel state afterwards

After Ctrl+C, the kernel survives but the namespace may be left in a partially executed state — variables assigned before the interrupt persist. After Stop or a timeout kill, the kernel is restarted and nothing survives. Critically, finally blocks and atexit handlers only get a chance to run on the KeyboardInterrupt path; a force-killed kernel runs no Python cleanup.

Orphaned child processes: no guarantee

Spyder provides no general cleanup guarantee for processes your script spawned. If the script launched children via subprocess.Popen or multiprocessing, killing the kernel does not reliably reap grandchildren — they can be orphaned, and what survives depends on platform and spawn method (fork vs spawn). On Windows, signal delivery differs (CTRL_BREAK_EVENT / GenerateConsoleCtrlEvent rather than POSIX signals), making in-process interrupts to subprocesses less reliable, so forceful termination is more commonly the effective outcome there.

How to verify on your installation

1. Confirm your version (Help → About) and that the timeout setting exists under Preferences → General → Advanced — this is version-sensitive (assumes Spyder 5.x/6.x).
2. Run while True: pass with a short timeout configured; press Ctrl+C mid-run and confirm the interrupt fires before the timeout.
3. Repeat with the Stop button and confirm the namespace is cleared (kernel restarted), not merely interrupted.
4. Have a script spawn subprocess.Popen(['sleep', '300']), trigger each cancellation path, and check the OS process list for survivors.

One caveat: exact timeout semantics are version-dependent, so treat the above as the well-established 5.x/6.x behavior and verify against your installed release.