CoroutineContext: un mapa indexado por tipo

El contexto es probablemente la pieza de las corrutinas que más gente usa a diario sin haber mirado nunca dentro. Se pasa un dispatcher a un launch, se añade un CoroutineName para que los registros se lean, se recuerda vagamente que ahí vive un Job, y el conjunto funciona. Funciona hasta el día en que una excepción no llega al manejador que habías instalado, o en que un hijo hereda un dispatcher que no esperabas, o en que dos sumas escritas en distinto orden producen comportamientos distintos. Todos esos casos dejan de ser misteriosos en cuanto se acepta un hecho estructural: CoroutineContext no es configuración, es una colección inmutable indexada por tipo, con un álgebra propia y una regla de herencia estricta que se aplica en cada creación de corrutina sin excepciones. Esta lección desmonta esa estructura hasta que sus consecuencias se vuelven predecibles antes de ejecutar el programa.

Un conjunto que se comporta como un mapa

La interfaz declara cuatro operaciones y ninguna de ellas es accidental. Hay una lectura indexada, un plegado que permite recorrer todos los elementos, una suma que combina dos contextos y una resta que elimina el elemento asociado a una clave. Lo llamativo es la firma de la lectura: recibe una clave paramétrica y devuelve un valor del mismo parámetro de tipo. Eso significa que el contexto es un mapa heterogéneo con tipado estático, algo que un mapa normal no puede ofrecer porque perdería el tipo del valor al recuperarlo.

public interface CoroutineContext {
    public operator fun <E : Element> get(key: Key<E>): E?
    public fun <R> fold(initial: R, operation: (R, Element) -> R): R
    public operator fun plus(context: CoroutineContext): CoroutineContext
    public fun minusKey(key: Key<*>): CoroutineContext

    public interface Key<E : Element>

    public interface Element : CoroutineContext {
        public val key: Key<*>
    }
}

La segunda sutileza es que Element extiende CoroutineContext. Un elemento suelto es también un contexto de un solo miembro, y por eso se puede pasar un dispatcher allí donde se espera un contexto completo sin envolverlo en nada. Esta autorreferencia elimina toda distinción entre el contenedor y lo contenido, y es lo que permite que el operador de suma acepte indistintamente elementos y combinaciones. El contexto vacío es un objeto propio, EmptyCoroutineContext, que actúa como elemento neutro de esa suma.

flowchart LR
A[CoroutineContext] --> B[EmptyCoroutineContext]
A --> C[Element]
A --> D[CombinedContext]
C --> E[Job]
C --> F[ContinuationInterceptor]
C --> G[CoroutineName]
C --> H[CoroutineExceptionHandler]
D --> C
D --> D

La tercera sutileza es la clave. Cada elemento declara una propiedad key cuyo valor es, por convención universal en la librería, el companion object de su propia clase. La clave no es una cadena ni un identificador arbitrario: es un objeto único ligado al tipo, y de ahí se sigue la invariante central de toda la estructura. En un contexto no puede haber dos dispatchers ni dos nombres ni dos manejadores, porque comparten clave. Un contexto no es una lista de opciones acumuladas sino un conjunto donde cada categoría aparece a lo sumo una vez.

Los cuatro elementos que casi siempre viajan

Leer cualquiera de ellos desde dentro de una corrutina es una consulta ordinaria sobre el mapa, y la propiedad coroutineContext está disponible en toda función suspendida sin necesidad de recibirla como parámetro, porque el compilador la obtiene de la continuación oculta que ya está pasando.

suspend fun inspeccionar() {
    val ctx = coroutineContext
    println(ctx[CoroutineName]?.name)              // la clave es el companion
    println(ctx[Job]?.isActive)
    println(ctx[ContinuationInterceptor])          // aqui aparece el dispatcher

    // Plegado sobre todos los elementos presentes
    val cuantos = ctx.fold(0) { acc, _ -> acc + 1 }
    println("elementos en el contexto: $cuantos")
}

Que la clave del dispatcher sea ContinuationInterceptor y no algo llamado dispatcher no es una curiosidad histórica sino una decisión de capas. La interceptación de continuaciones pertenece al lenguaje y vive en la librería estándar; el despacho a hilos pertenece a la librería de corrutinas y se implementa como un caso particular de esa interceptación. Por eso un dispatcher personalizado no tiene que inventar ninguna clave: hereda la que ya existe, y automáticamente desplaza a cualquier otro dispatcher del contexto al sumarse.

La suma y sus leyes

El operador de suma toma dos contextos y devuelve uno nuevo, siempre nuevo, porque toda la estructura es inmutable. La regla de resolución es la única que hay que memorizar y se enuncia en una línea: cuando ambos lados contienen un elemento con la misma clave, gana el de la derecha. De ahí se sigue que la suma es asociativa pero no conmutativa, y que escribir las sumas en el orden equivocado produce silenciosamente un comportamiento distinto sin ningún aviso del compilador.

val base = Dispatchers.Default + CoroutineName("base")
val ajustado = base + Dispatchers.IO           // gana IO, el nombre sobrevive
val invertido = Dispatchers.IO + base          // gana Default, el nombre sigue igual

val sinNombre = ajustado.minusKey(CoroutineName)
val neutro = EmptyCoroutineContext + ajustado  // identico a ajustado

Hay una excepción de la que casi nadie se acuerda y que es la única regla especial de todo el álgebra: cuando el lado derecho contiene un manejador de excepciones y el izquierdo un interceptor, o cualquier otra combinación, la suma sigue la regla general; pero al sumar un contexto que contiene un Job con otro que también lo contiene, el resultado conserva únicamente el de la derecha y con ello se rompe el vínculo de paternidad. Ese es el mecanismo exacto por el que pasar un Job explícito convierte un hijo en una raíz, y conviene verlo como un caso particular de la regla y no como una anomalía.

Internamente, sumar dos elementos produce un CombinedContext, una lista enlazada donde cada nodo guarda un elemento y el resto. La consulta recorre esa cadena comparando claves por identidad. La consecuencia práctica es que un contexto con cuatro elementos se lee en cuatro comparaciones de referencia, un coste despreciable frente a cualquier suspensión, y que sumar contextos dentro de un bucle caliente asigna un objeto por nodo, un coste que sí conviene evitar construyendo el contexto una vez fuera.

La herencia del padre al hijo

Cada constructor de corrutinas recibe un contexto opcional, y lo que acaba ejecutándose no es ese contexto sino el resultado de una fórmula fija. La librería toma el contexto del ámbito padre, le suma el contexto que has pasado como argumento y le suma un Job nuevo creado para esta corrutina, cuyo padre es el Job que venía heredado. Si tras ese cálculo no hay ningún interceptor, se añade el dispatcher por defecto.

val padre = CoroutineScope(Dispatchers.Default + CoroutineName("padre"))

padre.launch(CoroutineName("hijo")) {
    // dispatcher: heredado del padre
    // nombre: sustituido por el argumento
    // Job: nuevo, con el Job del padre como progenitor
    println(coroutineContext[CoroutineName]?.name)
}

Nótese que las funciones suspendidas ordinarias no participan de esta fórmula. Una función marcada como suspendida no crea corrutina alguna: se ejecuta dentro de la que ya existe y ve exactamente su contexto. Solo los constructores de corrutinas y las funciones que cambian de contexto derivan uno nuevo, y esa distinción es la que hace predecible dónde corre cada línea.

La asimetría del Job es el punto que hay que interiorizar. Todos los elementos del contexto se heredan por referencia: el hijo comparte el mismo objeto dispatcher, el mismo nombre y el mismo manejador que el padre. El Job, en cambio, nunca se hereda; se hereda su posición en el árbol. Si se heredase el objeto, cancelar un hijo cancelaría al padre y a todos sus hermanos, y la concurrencia estructurada dejaría de existir. Por eso pasar explícitamente un Job como argumento a un constructor de corrutinas rompe el vínculo con el padre y crea una raíz nueva, un error frecuente que convierte una jerarquía cuidadosamente diseñada en un conjunto de tareas huérfanas.

flowchart TD
A[Contexto del ambito padre] --> D[Suma de los tres]
B[Contexto pasado como argumento] --> D
C[Job nuevo con padre asignado] --> D
D --> E{Hay interceptor}
E -->|si| F[Contexto final del hijo]
E -->|no| G[Se anade el dispatcher por defecto]
G --> F