Concurrencia mal entendida: tareas huérfanas, `@MainActor` de parche y colas heredadas

La concurrencia estructurada de Swift no es una sintaxis más cómoda para lo que ya hacíamos: es un modelo distinto con reglas propias sobre quién es dueño del trabajo, quién espera su resultado y qué ocurre cuando alguien cancela. Migrar traduciendo mecánicamente cada bloque en una Task, cada acceso a la interfaz en un @MainActor y cada cola serie en un candado disfrazado produce un programa que compila, que parece moderno y que ha perdido todas las garantías que justificaban el cambio. Los tres antipatrones de esta lección aparecen juntos porque tienen una misma causa: se conservó el modelo mental de las devoluciones de llamada y se le puso encima un vocabulario nuevo. El refactor no consiste en anotar mejor, consiste en decidir de nuevo quién posee cada pieza de trabajo.

Tareas huérfanas

Una Task creada con el inicializador no es parte de ninguna jerarquía: hereda el contexto de aislamiento y las prioridades, pero nadie la espera y nadie la cancela salvo que alguien guarde el identificador. En código de interfaz aparece por decenas, una por cada acción del usuario, y cada una de ellas es una promesa de trabajo que sobrevive al objeto que la lanzó.

final class ListaVM {
    func cargar() {
        Task { self.items = await api.traer() }        // nadie la posee
    }
    func refrescar() {
        Task { self.items = await api.traer() }        // ni esta
    }
}

Los tres fallos son acumulativos. Primero, la cancelación no llega: cerrar la pantalla no detiene la descarga y el usuario paga datos por una vista que ya no existe. Segundo, no hay orden: si cargar y refrescar se solapan, gana la que termine antes, que no tiene por qué ser la más reciente, y la lista muestra datos viejos de forma intermitente. Tercero, los errores desaparecen: una Task sin await sobre su valor se traga cualquier excepción sin dejar rastro.

@MainActor
final class ListaVM {
    private var tarea: Task<Void, Never>?

    func recargar() {
        tarea?.cancel()                                 // el trabajo tiene dueno
        tarea = Task {
            do { items = try await api.traer() }
            catch is CancellationError { }
            catch { self.error = error }                // los fallos existen
        }
    }
    deinit { tarea?.cancel() }
}

flowchart TD
A[Evento del usuario] --> B{Quien posee el trabajo}
B -- Nadie --> C[Tarea huerfana]
C --> C1[Sin cancelacion]
C --> C2[Sin orden garantizado]
C --> C3[Errores tragados]
B -- Una propiedad o un grupo --> D[Trabajo cancelable y observable]
D --> D1[Se cancela al desaparecer la vista]
D --> D2[La ultima peticion gana siempre]

Cuando el trabajo es concurrente de verdad —varias descargas simultáneas— la respuesta no es lanzar varias tareas sueltas sino un grupo, que es estructurado por construcción: espera a todos sus hijos, propaga la cancelación hacia abajo y el primer error hacia arriba.

let imagenes = try await withThrowingTaskGroup(of: (Int, Imagen).self) { grupo in
    for (i, url) in urls.enumerated() {
        grupo.addTask {
            let img = try await descargar(url)
            return (i, img)
        }
    }
    var salida = [Int: Imagen]()
    for try await (i, img) in grupo { salida[i] = img }
    return urls.indices.map { salida[$0]! }
}

@MainActor como analgésico

El segundo antipatrón se reconoce por su trayectoria: el compilador señala un acceso no aislado, se añade @MainActor a la función, aparece otro diagnóstico más arriba, se añade a la clase, y al cabo de un mes el módulo entero está anotado. Ha desaparecido el error y también la concurrencia: todo el trabajo compite por un único ejecutor, el mismo que dibuja la pantalla.

El síntoma clínico es una interfaz que se atasca al procesar datos, con el perfilador mostrando trabajo de cómputo puro en el hilo principal. La causa no es @MainActor, que hace exactamente lo que promete; es haberlo usado como respuesta a un diagnóstico en lugar de como decisión sobre qué pertenece a la interfaz.

// Parche: todo al hilo principal para que el compilador calle
@MainActor
final class Procesador {
    func procesar(_ datos: [Registro]) -> Resumen { /* calculo pesado */ }
}

// Decision: el calculo no es interfaz, y lo dice su firma
struct Procesador: Sendable {
    func procesar(_ datos: [Registro]) async -> Resumen { /* ... */ }
}

@MainActor
final class PantallaVM {
    private(set) var resumen: Resumen?
    func actualizar(_ d: [Registro]) async {
        resumen = await Procesador().procesar(d)     // solo la escritura es UI
    }
}

La regla es de frontera: @MainActor marca lo que debe ocurrir en el hilo principal —estado observado por la vista, llamadas a la interfaz— y nada más. Todo lo demás debería ser Sendable y libre de aislamiento, para que el compilador pueda moverlo donde convenga. Cuando el diagnóstico persiste tras aplicar esa frontera, lo que está mal no es la anotación: es que un tipo mutable de referencia está cruzando dominios y hay que convertirlo en valor o encerrarlo en un actor.

El DispatchQueue heredado

La cola serie sigue siendo una herramienta correcta en muchos sitios, y no hay que migrarla por estética. Lo que no se puede es mezclarla con async de la manera en que suele hacerse: envolviendo la cola en una función asíncrona que espera con un semáforo, o llamando a DispatchQueue.main.sync desde código aislado.

// Antipatron: bloquea un hilo del pool cooperativo
func leer() async -> Datos {
    let sem = DispatchSemaphore(value: 0)
    var r: Datos!
    cola.async { r = self.leerInterno(); sem.signal() }
    sem.wait()                                        // hilo bloqueado
    return r
}

// Puente correcto: la suspension es real, no simulada
func leer() async -> Datos {
    await withCheckedContinuation { cont in
        cola.async { cont.resume(returning: self.leerInterno()) }
    }
}

La diferencia importa porque el grupo de hilos cooperativos tiene tantos hilos como núcleos y da por supuesto que ninguna tarea los bloquea. Un semáforo dentro de una función async viola esa suposición; con suficientes llamadas simultáneas el sistema se queda sin hilos disponibles y se produce un interbloqueo por inanición que no aparece en desarrollo y sí con carga real.

Un criterio de migración

Migrar bien un módulo se hace de dentro hacia fuera, no al revés. Primero se identifican los estados mutables y se decide, para cada uno, quién lo custodia: un actor si se comparte, @MainActor si es interfaz, nadie si se convierte en valor. Después se marcan como Sendable los tipos que cruzan fronteras, empezando por los que ya son struct de campos inmutables. Solo al final se tocan las firmas, y para entonces la mayoría de los async que hacían falta ya se han hecho evidentes.