Why did Kotlin choose cooperative cancellation instead of forcibly interrupting coroutines? What are the trade-offs and implications for blocking work?

## The problem with forced termination Older Java had `Thread.stop()` and `Thread.destroy()`; both are deprecated/removed because **asynchronously killing a thread is unsafe**: - It can stop a thread mid-mutation, leaving shared objects in an **inconsistent state**. - It can release **monitors/locks** abruptly, exposing partially-updated data to other threads. - `finally` blocks and resource cleanup may not run predictably. Thread interruption (`Thread.interrupt()`) is itself **cooperative** for the same reasons — it sets a flag that blocking calls check. ## Kotlin's choice Kotlin coroutines deliver cancellation as a `CancellationException` thrown **only at suspension points**. This means: - The coroutine is interrupted at a **well-defined boundary** where its own invariants are intact. - Normal exception unwinding runs `try/finally` and `use { }` blocks, so resources close deterministically. - It composes with **structured concurrency**: cancelling a scope cancels children at their suspension points and waits for orderly shutdown. ```kotlin launch { val file = openFile() try { while (true) { file.append(next()); delay(50) } // cancels cleanly here } finally { file.close() // always runs on cancellation } } ``` ## The trade-off: you must cooperate The price is that **non-suspending work is opaque to cancellation**: - A tight CPU loop ignores `cancel()`. Fix: call `yield()` or `ensureActive()` periodically, or guard the loop with `while (isActive)` (these helpers are a sibling topic, but they're the remedy). - A blocking JDK/IO call (`Thread.sleep`, blocking socket, JDBC) won't be interrupted. Fix: wrap with `suspendCancellableCoroutine` + `invokeOnCancellation`, or run it where interruption is wired up (`runInterruptible { ... }` bridges JVM thread interruption to coroutine cancellation). ## Asynchrony of cancel() Because cancellation is delivered cooperatively, `cancel()` returns **immediately** and the coroutine may still be unwinding. Use `join()` or `cancelAndJoin()` to await actual completion. This is why you can't assume resources are freed the instant `cancel()` returns. ## Implications for API and library design - Long-running library functions should sprinkle cancellation checks so callers can cancel them. - Suspend functions should honor cancellation (use cancellable primitives) so they integrate with structured concurrency. - Cleanup that must suspend belongs in `withContext(NonCancellable)` (sibling topic) so it isn't itself cut short. ## Summary Cooperative cancellation trades **automatic preemption** for **safety, deterministic cleanup, and structured concurrency**. The developer's responsibility is to insert cancellation points into otherwise opaque CPU/blocking work.