Why do modern concurrency runtimes make cancellation cooperative — the task must observe a signal — instead of forcibly terminating it from outside, and where does a thread-level interruption flag fit into that model?

## The two designs **Forced (preemptive) termination**: an external actor stops the task wherever it happens to be executing. **Cooperative cancellation**: the external actor sets a signal, and the task stops at points of its own choosing. Essentially all modern runtimes chose the second, and the reason is not politeness — it is that the first is unimplementable safely on shared mutable state. ## Why forced termination breaks things Consider a task stopped at an arbitrary machine instruction: - **Broken invariants.** Multi-step updates ("decrement A, increment B", "append node, fix up the parent pointer", "write header, write payload") are momentarily inconsistent by construction. Stop in the middle and the data structure is corrupt — and it is *shared*, so every other task now reads corruption. The task's own memory would be reclaimed by killing it; the shared state it was editing would not. - **Locks are a dilemma with no good answer.** If the runtime releases the locks the dying task held, other tasks proceed over inconsistent data. If it keeps them held, everyone waiting deadlocks forever. There is no third option, because "is the protected state consistent right now?" is knowable only to the code, not the runtime. - **Cleanup cannot run.** Scope-exit / finally handlers are written assuming a coherent state and a live stack. Injecting an unwind at an arbitrary instruction — including inside the allocator, inside a lock's own internals, inside library code with no unwinding support — means the cleanup may itself fault or block. - **Resources leak.** Sockets, file handles, temp files, and off-heap buffers are released by cleanup code that never ran. - **The failure is non-deterministic.** The damage depends on exactly where the stop landed, so it reproduces once in a thousand runs and never in a test. The same argument in one line: *every instruction becomes a potential unwind point, so nothing can be assumed invariant anywhere.* ## What cooperation buys By requiring the task to observe the signal, the set of stopping points shrinks from *every instruction* to *the points the author chose*. At those points: - the task's own invariants hold; - it can unwind through the normal error path, so scope-exit/cleanup handlers run in order; - locks are released by that normal unwinding, with the protected state consistent; - the outcome is reportable: the owner learns the task ended as *cancelled*. The cost is that cancellation is **not instantaneous** and **not guaranteed**. A task in a tight compute loop with no checkpoint, or one blocked in an operation that ignores the signal, will not stop. That is a real, accepted trade: bounded latency and the possibility of a stuck task, in exchange for never corrupting shared state. ## Interruption as the thread-level analogue Before task-level runtimes, the same contract existed at thread granularity. Each thread carries a single **interruption bit**. Setting it does two things: it becomes visible to code that polls it, and blocking operations that participate in the protocol (sleeps, waits, many I/O calls) return early with an "interrupted" indication instead of continuing to block. Crucially it still does not stop the thread — the thread's code decides whether to unwind, and it must not silently swallow the signal, because swallowing it means the next layer up never learns cancellation was requested (the usual convention is to re-set the flag or translate it into a cancellation outcome the caller can see). Compared with a per-task cancellation token or context, an interruption bit is *ambient* (no API changes needed) but *coarse*: it identifies a thread, not a logical task. On a pooled thread the bit can be delivered after the intended task has finished, hitting whatever unrelated task runs next; it is a single bit that cannot carry a deadline or a cause; and it does not follow work that hops threads, which is exactly what async runtimes do. Explicit tokens fix identity and composition at the cost of threading a parameter through every call. ## The one legitimate forced stop Killing a whole **process** is safe in the way killing a task is not: the process boundary means no other live code shares its address space, and the OS reclaims memory, file descriptors and locks wholesale. Anything that survives (files on disk, rows in a database, messages already sent) still needs idempotent recovery — which is why supervised, restartable processes are a legitimate design and "forcibly kill this one task" is not. ## What this implies for how you write tasks Since the runtime cannot stop you safely, being stoppable is a property you write in: check the signal in long loops, prefer interruptible/timeout-bearing blocking calls, never catch and discard an interruption or cancellation, and keep the work between checkpoints short enough that the resulting latency is acceptable.