`NonCancellable` section can be cancelled when combined with another context

[andrew-k-21-12]

This can be my misunderstanding about how NonCancellable is expected to work, but it seems like a bug or some missing documentation note by default.

Used kotlinx-coroutines-core of version 1.9.0 in a JVM example project.

The code to reproduce:

fun main(): Unit = runBlocking {
    val job = launch {
        while (true) {
            println("Before NonCancellable section ${Thread.currentThread().name}")
            withContext(NonCancellable + Dispatchers.IO) {
                println("Inside NonCancellable section ${Thread.currentThread().name}")
            }
            println("After NonCancellable section ${Thread.currentThread().name}")
        }
    }
    delay(20)
    println("Trying to cancel the job ${Thread.currentThread().name}")
    job.cancelAndJoin()
    println("The job has been finished ${Thread.currentThread().name}")
}

The only call which checks for the cancellation inside the launch { ... } section is withContext(...) { ... }. Since the coroutine has been launched, I expected it to run in the cycle forever due to the NonCancellable context.

But it actually ends with the following logs:

Before NonCancellable section main
Inside NonCancellable section DefaultDispatcher-worker-1
Trying to cancel the job main
The job has been finished main

In other words, it gets cancelled anyway somewhere at the moment of exiting from the withContext section.

Changing the order of NonCancellable + Dispatchers.IO to Dispatchers.IO + NonCancellable doesn't update the result behavior anyhow.

Removing Dispatchers.IO or putting it as a nested call inside make the execution work as I expect it to:

withContext(NonCancellable) {
    withContext(Dispatchers.IO) {
        println("Inside NonCancellable section ${Thread.currentThread().name}")
    }
}

Is this cancelling behavior described above expected? Or do I miss some important rule to use NonCancellable?

[dkhalanskyjb]

In other words, it gets cancelled anyway somewhere at the moment of exiting from the withContext section.

Yes, that's expected. Please see the https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/with-context.html docs.

This suspending function is cancellable. It immediately checks for cancellation of the resulting context and throws CancellationException if it is not active.

Note that the result of withContext invocation is dispatched into the original context in a cancellable way with a prompt cancellation guarantee, which means that if the original coroutineContext in which withContext was invoked is cancelled by the time its dispatcher starts to execute the code, it discards the result of withContext and throws CancellationException.

The code inside withContext(NonCancellable) is guaranteed not to get cancelled, but returning from withContext back to the original context and entering the withContext block may still get cancelled.

Removing Dispatchers.IO [...] make the execution work as I expect it to

That's because then you only have a single thread, so cancellation actually never even happens: you never yield the thread that could call cancel.

putting it as a nested call inside make the execution work as I expect it to

That's trickier. Neither of the two reasons for withContext to throw CancellationException gets fulfilled: neither does the resulting context get cancelled (rule 1), because it's NonCancellable, nor does the prompt cancellation kick in, as no actual dispatch happens when leaving the withContext(NonCancellable) block: it just directly proceeds to execute code in the same thread.

[andrew-k-21-12]

Thank you for the clarifications. So, if shortly, the key point here is that withContext checks for the cancellation all the time and can be cancelled regardless from its context argument. In other words, NonCancellable affects only what's inside of withContext's block but not the withContext call itself. So to guarantee some withContext(NonCancellable) { ... } call to be invoked I need to use another approach.

[dkhalanskyjb]

Yep. Passing CoroutineStart.ATOMIC to launch may also be important in your use case, PTAL.

[andrew-k-21-12]

I need to correct my previous comment above:

So, if shortly, the key point here is that withContext checks for the cancellation all the time and can be cancelled regardless from its context argument.

According to the docs for withContext:

This suspending function is cancellable. It immediately checks for cancellation of the resulting context and throws CancellationException if it is not active.

In the case of withContext(NonCancellable) { ... } (and I guess when composite contexts with NonCancellable included are used) the resulting context will be non-cancellable, so I think CancellationException won't be thrown beforehand, and we will always execute the block inside withContext. The only thing can be cancelled — is the moment of returning from withContext to some other cancellable context.