What is a cancellation checkpoint, and how would you make a 30-second CPU-bound computation loop cancellable? What determines how quickly cancellation actually takes effect?

## Definition A **cancellation checkpoint** (also called a cancellation point, suspension point, or safepoint for cancellation) is a location in a task's execution where two things are true: 1. the task **reads the cancellation signal**, and 2. **abandoning right there is safe** — the task's own invariants hold, and unwinding from this point will run cleanup correctly. Cooperative cancellation is exactly the discipline of having enough of these, in the right places. ## Where checkpoints come from **Implicit, from the runtime.** In coroutine/async models, every point where the task can suspend is naturally a checkpoint: the runtime already has control there, so it can resume the task with a cancellation instead of a value. That is why async code often "just works" with cancellation as long as it awaits something regularly. **Implicit, from blocking APIs.** Interruption-aware blocking calls typically check the signal on entry and abort with an interrupted status if the signal arrives while parked. Timed variants ("wait up to 200 ms") give you a bounded checkpoint interval even if the underlying operation itself is not interruptible. **Explicit, written by you.** Pure computation — matrix work, parsing a big buffer, simulation, compression — never blocks and never yields, so the runtime gets no opportunity to intervene. Here you must poll. ## Making a CPU-bound loop cancellable The standard shape: ``` CHECK_EVERY = 4096 for i in 0..N: if i % CHECK_EVERY == 0 and cancelled(): cleanup_partial() raise Cancelled step(i) ``` Design points: - **Make the read cheap.** The signal should be a simple flag readable without synchronisation stronger than an ordinary atomic/volatile-style read. Taking a lock, allocating, or calling into a registry per iteration turns cancellation support into a performance bug. Reading a stale value briefly is fine — it only delays the stop by microseconds. - **Amortise the check.** Testing every 4096 iterations makes the check's cost negligible while keeping latency in the sub-millisecond to millisecond range for typical iteration costs. The counter-and-mask trick avoids even the branch cost being significant. - **Put it in the loop that owns the time.** If the inner loop body is nanoseconds and the outer loop runs 10,000 times over 30 seconds, check in the outer loop. Checking in the innermost loop of a hot kernel can defeat vectorisation and cost real throughput. - **Do not check inside a critical section that must complete.** A checkpoint in the middle of a two-step state update violates rule (2) above: you would abandon with the invariant broken. Put checkpoints at the boundaries between units of work, not inside them. - **Prefer chunking.** Restructure the work as a sequence of bounded units ("process 10,000 rows", "one tile of the image"), with the checkpoint between units. This also gives you natural progress reporting and a place to persist partial state if the work is resumable. ## Cancellation latency The useful formula: **latency ≈ (worst-case time between consecutive checkpoints) + (time to unwind and run cleanup)** Both halves matter. A loop that checks every 100 ms but whose cleanup flushes a 2-second write is a 2-second cancellation. Latency composes down a task tree, too: a parent cannot finish cancelling until its slowest descendant has passed a checkpoint and cleaned up, so the tree's latency is dominated by its worst path — a single un-checkpointed leaf pins the whole subtree. You size the interval against a **budget**, not a feeling. If shutdown grants 10 seconds of grace and you want three retries of escalation inside it, per-task cancellation must land in well under a second; if the caller's timeout is 200 ms and you want the work to actually stop when the client disconnects, checkpoints need to be tens of milliseconds apart. ## Anti-patterns - **A loop with no checkpoint at all**, then blaming the framework for "cancellation not working". The framework can only deliver the signal; observing it is the task's job. - **Checking only before the loop.** The signal almost always arrives *during* the work. - **Checking, then continuing anyway** ("log it and carry on"), which converts cancellation into a warning message. - **A hidden un-checkpointed span inside a library call** — a third-party parse or compress step that runs for seconds. Wrap such calls with a smaller unit of input if you can; otherwise document the latency floor they impose. - **Cleanup with no bound.** The second half of the latency formula deserves its own budget. ## Testing it Cancellability is testable: start the task, cancel after a fixed delay, and assert both that the task terminated within the latency budget and that its resources were released. A test that only asserts "cancel() returned" proves nothing, because the signal always returns immediately regardless of whether anyone is listening.