Cancelación cooperativa: la excepción que no es un error

Detener un cómputo ajeno por la fuerza es un problema clásico de la informática y tiene una solución conocida y una respuesta bien establecida sobre por qué esa solución es mala. Java ofreció durante años un método para matar un hilo, y acabó marcándolo como obsoleto porque interrumpir a alguien en un punto arbitrario deja los invariantes rotos: candados tomados que nadie soltará, ficheros a medio escribir, estructuras que quedan en un estado que ninguna línea del programa contempla. La alternativa razonable es que el trabajo no se mate sino que se le pida terminar, y que él elija en qué punto seguro obedecer. A eso se le llama cancelación cooperativa, y la palabra cooperativa es una advertencia disfrazada de tecnicismo: si el código no coopera, no se cancela. Kotlin implementa esa petición como una excepción, lo cual permite reutilizar toda la maquinaria de desenrollado de la pila que el lenguaje ya tenía, pero introduce una consecuencia con la que hay que convivir, y es que el mecanismo de limpieza y el mecanismo de captura de errores comparten sintaxis y se estorban.

La cancelación es una excepción con estatuto especial

Cancelar un Job no interrumpe nada de inmediato: cambia su estado a cancelándose y hace que, la próxima vez que la corrutina pase por un punto de suspensión, ese punto lance una CancellationException en lugar de continuar. A partir de ahí la excepción se comporta como cualquier otra: desenrolla la pila, dispara los bloques finally que encuentre y termina la corrutina. La diferencia está en cómo la trata el resto del sistema.

val trabajo = scope.launch {
    try {
        repeat(1_000) { i ->
            delay(100)           // punto de suspension: aqui se puede cancelar
            println("paso $i")
        }
    } finally {
        println("limpieza")      // se ejecuta igualmente
    }
}

delay(350)
trabajo.cancelAndJoin()

Esa excepción es especial en un sentido preciso: cuando llega al padre, el padre no la interpreta como un fallo. Una corrutina cancelada no contamina a sus hermanos ni convierte al ámbito en fallido, porque la cancelación es la forma normal de terminar y no una anomalía. Por eso CancellationException es el único tipo de excepción que sube por el árbol sin activar la propagación de fallos, y por eso al inspeccionar un ámbito cancelado no aparece ningún error en el registro.

El código que no comprueba nunca se cancela

De la explicación anterior se sigue el hecho más importante y menos intuitivo del mecanismo: la cancelación solo puede ocurrir en un punto de suspensión o en una comprobación explícita. Un bucle que solo hace aritmética no tiene ni una cosa ni la otra, así que ignora por completo la cancelación y sigue hasta el final, con el agravante de que su ámbito ya lo considera cancelado y por tanto nadie lo está esperando.

// Este bucle ignora la cancelacion por completo
val incancelable = scope.launch(Dispatchers.Default) {
    var i = 0L
    while (i < 5_000_000_000) {
        i += hash(i)          // ningun punto de suspension
    }
}
incancelable.cancel()         // no detiene nada

Hay tres familias de código que caen en esta trampa y conviene identificarlas por separado, porque cada una tiene su propio remedio. La primera es el cómputo puro, bucles largos de cálculo sin suspensión alguna, y se arregla insertando comprobaciones. La segunda es la llamada bloqueante heredada, una lectura de socket o una consulta a base de datos que no sabe nada de corrutinas; ahí no hay comprobación que valga y la solución pasa por envolverla de modo que la cancelación se traduzca a la interrupción del hilo, con runInterruptible, o por cerrar el recurso desde fuera. La tercera es el bloque finally que quiere seguir trabajando tras la cancelación y descubre que ya no puede, y es el asunto de la última sección.

flowchart TD
A[Alguien invoca cancel] --> B[El Job pasa a cancelandose]
B --> C{El cuerpo alcanza un punto de cancelacion}
C -- Si --> D[Se lanza CancellationException]
C -- No --> E[El cuerpo sigue ejecutando hasta el final]
D --> F[Se ejecutan los bloques finally]
F --> G[El Job queda cancelado]

Devolverle al código la capacidad de obedecer

Hay tres formas de insertar un punto de cancelación en un cómputo y no son intercambiables. La primera es ensureActive, que comprueba el estado del contexto y lanza la cancelación si procede; es la elección por defecto porque es la más barata y la que expresa exactamente la intención. La segunda es yield, que además de comprobar cede el turno al planificador, permitiendo que otras corrutinas del mismo hilo avancen; se usa cuando el bucle podría monopolizar un despachador compartido. La tercera es leer isActive y salir del bucle por las buenas, que es la única adecuada cuando se quiere terminar de forma ordenada devolviendo un resultado parcial en lugar de propagar una excepción.

suspend fun sumarPesado(datos: List<Long>): Long {
    var total = 0L
    for ((i, d) in datos.withIndex()) {
        if (i % 1_000 == 0) currentCoroutineContext().ensureActive()
        total += transformar(d)
    }
    return total
}

// Variante que cede el turno en un despachador compartido
suspend fun recorrer(datos: List<Long>) {
    for (d in datos) {
        yield()
        procesar(d)
    }
}

La frecuencia de la comprobación es una decisión de ingeniería. Comprobar en cada vuelta de un bucle muy caliente añade un coste medible sin ganancia perceptible; comprobar cada mil o cada diez mil iteraciones acota la latencia de cancelación a una fracción de milisegundo, que es de sobra suficiente. El criterio correcto no es cuántas iteraciones sino cuánto tiempo puede tardar el trabajo en reaccionar sin que resulte molesto.

El caso de la llamada bloqueante heredada tiene su propia herramienta y conviene conocerla, porque el remedio ingenuo de envolverla en un despachador de entrada y salida no cancela nada: solo traslada el bloqueo a otro hilo. La función runInterruptible traduce la cancelación de la corrutina a una interrupción del hilo que ejecuta el bloque, que es el único lenguaje que entienden las API antiguas.

suspend fun leerFichero(ruta: Ruta): ByteArray =
    withContext(Dispatchers.IO) {
        runInterruptible { apiHeredada.leerBloqueante(ruta) }
    }

El tiempo límite es la otra cara de este mecanismo y funciona exactamente igual, porque withTimeout no hace nada mágico: lanza la cancelación sobre el bloque cuando expira el plazo. De ahí se sigue una consecuencia que sorprende a mucha gente y que ya está contenida en todo lo anterior, y es que un tiempo límite alrededor de código no cooperativo tampoco funciona. Ponerle un plazo a un bucle que nunca comprueba nada produce un plazo que se cumple en el papel y no interrumpe nada en la práctica.

Limpiar cuando ya se está muerto

Los bloques finally se ejecutan durante la cancelación, pero con una restricción importante: la corrutina ya está en estado cancelándose, así que cualquier función suspend invocada ahí dentro lanzará una CancellationException de inmediato. Esto significa que la limpieza sincrónica funciona y la limpieza que requiere suspensión, como cerrar una conexión remota o guardar un estado, no.

val trabajo = scope.launch {
    val recurso = abrir()
    try {
        usar(recurso)
    } finally {
        recurso.cerrarLocal()                 // sincrono: funciona
        withContext(NonCancellable) {
            recurso.avisarAlServidor()        // suspende: necesita el permiso
        }
    }
}

El elemento de contexto NonCancellable crea un Job que nunca se considera cancelado, de modo que dentro de ese bloque las funciones de suspensión vuelven a funcionar con normalidad. Es una excepción deliberada al modelo y hay que usarla con la disciplina que exige toda excepción a una regla: solo dentro de un finally, solo para limpieza y solo con operaciones acotadas en el tiempo, porque el código que hay dentro es, por definición, incancelable. Una llamada de red sin tiempo límite ahí dentro puede colgar indefinidamente un ámbito que el resto del programa cree ya terminado.