How does coroutine cancellation work internally?

What's really being asked

This question probes your understanding of the core principle of coroutine cancellation: it is cooperative, not preemptive. The interviewer is checking if you know that a coroutine must actively participate in its own cancellation. This distinguishes a senior candidate who understands the mechanics from someone who incorrectly equates job.cancel() with killing a thread or process.

The full answer

First, the job.cancel() call itself is non-blocking. It transitions the Job to a 'Cancelling' state, propagates the cancellation request to all its children jobs, and returns immediately. It does not stop anything on its own.

Second, the actual stop happens via a CancellationException. All suspending functions built into kotlinx.coroutines (like delay, yield, withContext) are 'cooperative'. Internally, they check the coroutine's job status before and during suspension. If the job is in the 'Cancelling' state, they throw a CancellationException instead of resuming normally.

Third, for long-running computations without suspension points, the coroutine must manually cooperate. A tight loop performing CPU-bound work will ignore a cancellation request because it never calls a cooperative suspend function. To fix this, the loop must periodically check the isActive property of its CoroutineScope and exit if it becomes false.

The mistakes people make

Saying that job.cancel() stops the underlying thread. This is the most common and significant red flag. Coroutines are abstractions over threads, and cancellation is a feature of the coroutine's state machine, not the thread it happens to be running on.

Stating that execution stops immediately. Cancellation is a request. The coroutine will continue to run until it reaches the next suspension point or an isActive check. Any code in a finally block will still execute for cleanup.

Describing catching and swallowing a CancellationException. While you can catch it to perform cleanup (e.g., closing a file), it must be re-thrown. Swallowing it effectively ignores the cancellation request, leaving the coroutine and its parent in an inconsistent state.

What usually comes next

How would you make a long-running, non-suspending function cancellable? The answer is to pass in the CoroutineScope and periodically check isActive inside the function's loop.

What is the difference between cancel() and cancelAndJoin()? cancel() sends the request and moves on. cancelAndJoin() sends the request and then suspends until the coroutine has fully completed its cancellation process, including any finally blocks.

What is NonCancellable used for? It's a context used to run suspending code that must not be cancelled, such as critical cleanup operations like writing a file to disk or committing a database transaction in a finally block.

A concrete example

Imagine a coroutine launched with val job = launch { ... }. Inside, it has a loop: while (i < 1_000_000_000) { i++ }. If you call job.cancel(), this coroutine will not stop. It will run to completion because it never suspends or checks its state. The correct, cooperative version is while (isActive && i < 1_000_000_000) { i++ }. Now, when job.cancel() is called, isActive will eventually become false, and the loop will terminate gracefully.