Stopping a long cell should not always discard variables prepared earlier. Leaving an unresponsive computation busy forever is also unacceptable. I separated requesting an interrupt from closing the kernel process, then added a bounded fallback for an execution that does not respond.
Interrupt first records the intention to stop
Notebook interruption sets the cancelled flag and, when a kernel exists, sends both host stop and an interrupt command. The Python controller forwards that command through KernelManager. It gives the cell an opportunity to stop cooperatively without creating a replacement kernel.
When computation responds, the same kernel can remain available and earlier variables may survive. This is not a guarantee that every library or native call responds. Sending a stop request and observing a terminated cell are different facts. Execution state still needs to establish whether the interruption actually settled.
Escalate only if the same execution is still present
When a cell was executing, a three-second callback checks that both the kernel object and execution identity still match. Only then does it request shutdown. A delayed interrupt timer must not terminate a later kernel or another cell. The ownership of the timeout matters as much as its duration.
Three seconds is the current product's fallback boundary, not a scientific guarantee suitable for every computation. Faster escalation can discard a chance to retain variables, while slower escalation can leave the operator uncertain about progress. The explanation preserves that tradeoff and the exact condition under which escalation occurs.
Shutdown also settles connection and cell waiters
Shutdown detaches the kernel, rejects readiness and cell waiters, closes sockets and server, and sends a shutdown command to the child controller. A later timer requests process termination if exit is slow. The cancellation path also waits for execution completion so busy-state cleanup can settle.
Closing the process loses Python memory variables. Saved notebook documents, outputs and item journals have different lifetimes and can remain available. Kernel termination is not document deletion. Knowing which state disappears and what can be reread determines what the next execution needs to prepare again.
Stopping cannot reverse an already delivered external change
Host stopping also participates in conditions that refuse further browser work. It does not undo input, storage or publication already delivered to a service. A server result can survive the local kernel. Starting that mutation again merely because the local status says cancelled can create duplication.
The original run and actual service outcome must be inspected first. Retaining variables or terminating a process cannot establish safe business replay. The stop button is not an undo operation for prior effects. Execution control and reconciliation of the business result need separate contracts and separate evidence.
Separate design intent from the execution tests actually available
This article reads interrupt, shutdown and Python command handling to explain state and timeout conditions. It does not send real interrupts to every native library. Existing startup-cancellation and execute-liveness unit tests concern their own different situations.
Reopening the shared file journal is not a process-interruption test either. Related uses of restart do not make verification scopes interchangeable. The design can explain why cooperative interruption may preserve variables and why terminated memory is lost without claiming successful behavior in environments that have not actually been tested.
Tell the operator what is retained and what is lost
A generic stop label is confusing if one case retains variables and another requires setup again. A request to interrupt, a settled cell and a terminated kernel need distinguishable explanations. Readable stopped state can reduce blind presses of the execution cell.
Business software likewise creates confusion when cancelling processing, closing a program and deleting saved material share one word. The aim is not more buttons but clearer lifetimes. Examining stopping behavior closely helps people understand their next choice, independently of how quickly the calculation itself runs.