El buzón: por qué el paso asíncrono disuelve la carrera

La promesa más citada del modelo de actores es que elimina las condiciones de carrera, y como toda promesa muy citada conviene desarmarla antes de creerla. Una condición de carrera necesita tres ingredientes a la vez: dos flujos concurrentes, una mutación y un dato compartido entre ambos. El buzón no elimina la concurrencia —los actores siguen avanzando a la vez— ni elimina la mutación —el estado del actor cambia en cada turno—. Elimina el tercer ingrediente, el compartir, y con eso basta para que la clase entera de defectos deje de ser expresable. A cambio aparece otra clase, más benigna pero muy real, que vive en el tiempo en vez de en la memoria y que hay que aprender a ver.

La atomicidad del turno

El turno es la unidad de ejecución de un actor: sacar un mensaje del buzón, aplicar el comportamiento, producir sus efectos y quedar listo para el siguiente. Mientras dura un turno ningún otro mensaje se procesa para ese mismo actor, así que la transición de estado es atómica respecto a todo lo demás. La propiedad que en el mundo de hilos se paga con un candado —exclusión mutua sobre el dato— aquí sale gratis de la forma del sistema, y la diferencia esencial es que un candado se puede olvidar y un turno no.

// Micro-runtime: la exclusion mutua no se pide, se deduce del bucle.
function correr(comportamiento: Comportamiento) {
  const buzon: Mensaje[] = []
  let ocupado = false

  function planificar() {
    if (ocupado) return
    ocupado = true
    queueMicrotask(() => {
      const mensaje = buzon.shift()
      if (mensaje !== undefined) {
        comportamiento = aplicar(comportamiento, mensaje) // turno completo
      }
      ocupado = false
      if (buzon.length > 0) planificar()
    })
  }

  return (mensaje: Mensaje) => {
    buzon.push(mensaje) // enviar es depositar, nunca ejecutar
    planificar()
  }
}

Lo notable de ese bucle es lo que no contiene: ninguna primitiva de sincronización, ninguna comprobación de propiedad, ningún orden de adquisición que documentar para evitar interbloqueos. La exclusión mutua es una consecuencia de que el estado solo se toque durante un turno y de que los turnos no se solapen. Un sistema de actores no puede sufrir un interbloqueo por candados porque no hay candados que adquirir en orden equivocado; puede sufrir bloqueos lógicos —dos actores esperando respuestas mutuas—, pero eso es un problema de protocolo, visible en el grafo de mensajes, no un problema de memoria invisible en el depurador.

Lo que el buzón no promete

El error caro no es creer que el buzón resuelve las carreras, sino extender esa confianza a garantías que nunca dio. Conviene separar el axioma del modelo, lo que ofrece cada implementación y lo que tú necesitas.

La fila crítica es la última, y de ella nace la clase de defectos que sustituye a las carreras. Un actor envía una petición, sigue recibiendo mensajes mientras espera —porque no puede bloquearse, ese es el trato— y cuando la respuesta llega, el estado que la motivó puede haber cambiado. La respuesta es correcta y llega a destiempo: es una respuesta rancia. El resultado observable se parece mucho a una carrera, con la diferencia decisiva de que ocurre entre mensajes y no dentro de la memoria, así que es reproducible, registrable y modelable.

Hay tres remedios y conviene conocer los tres. El primero es la correlación: cada petición lleva un identificador y la respuesta lo devuelve, de modo que el actor descarta las que no corresponden a su petición vigente. El segundo es la recepción selectiva de Erlang, que permite atender del buzón solo los mensajes que encajan con un patrón y dejar el resto para después; es potente y tiene un coste que se olvida, porque el buzón se recorre en busca del patrón y una cola larga convierte cada recepción selectiva en un barrido lineal. El tercero es apartar los mensajes que no tocan ahora en una reserva y devolverlos cuando el actor vuelva a un estado que los acepta.

El turno partido: por qué un await rompe el aislamiento

Toda la argumentación anterior descansa en que el turno es indivisible, y en un entorno con corrutinas esa premisa se puede violar sin darse cuenta. Si el manejador de un mensaje espera una promesa, el turno termina en ese punto: el planificador queda libre, otros mensajes del mismo actor se procesan, y la continuación se ejecuta después sobre un estado que ya no es el que leyó antes de esperar.

// Turno partido: el aislamiento desaparece en la linea del await.
async function manejarMal(mensaje: Mensaje) {
  const saldo = this.saldo              // lectura en el turno A
  const ok = await this.pasarela.cobrar(mensaje.importe) // el turno A TERMINA aqui
  if (ok) this.saldo = saldo - mensaje.importe // escritura en el turno B, con saldo rancio
}

Esas cuatro líneas reproducen exactamente la carrera de lectura y escritura del mundo de hilos, dentro de un modelo que presumía de haberla abolido. La lección práctica es severa y explica una restricción de diseño que muchos consideran arbitraria: en un runtime de actores serio, el manejador debe ser síncrono. El trabajo asíncrono no se espera dentro del turno, se delega a otro actor cuyo resultado vuelve como un mensaje corriente. Así el turno vuelve a ser atómico, la espera vuelve a ser un estado con nombre y la continuación vuelve a leer el estado en el momento en que actúa.

// Delegar en vez de esperar: la continuacion vuelve como mensaje.
function manejarBien(mensaje: Mensaje, yo: Direccion): Efecto {
  return {
    envios: [[pasarela, { tipo: 'cobrar', importe: mensaje.importe, responder: yo }]],
    creados: [],
    siguiente: cobrando(mensaje.importe), // estado explicito de espera
  }
}

flowchart LR
A[turno A completo] --> B[estado cobrando]
B --> C[llega respuesta de la pasarela]
C --> D[turno B completo]
B -. otro mensaje mientras espera .-> E[se aparca o se descarta]
style A fill:#a6e3a1,color:#11111b
style D fill:#a6e3a1,color:#11111b
style E fill:#f9e2af,color:#11111b

Contrapresión: un buzón ilimitado es una fuga

El buzón sin cota es la comodidad que se cobra tarde. Mientras la tasa de llegada sea menor que la de servicio, la cola vive corta y nadie la mira; en cuanto se invierte la relación, aunque sea durante un pico breve, la cola crece de forma monótona y el sistema no se degrada, se muere de memoria. La ley de Little lo dice sin adjetivos: el número medio de mensajes en el sistema es el producto de la tasa de llegada por el tiempo medio de permanencia, de modo que si el tiempo de servicio empeora un orden de magnitud, la cola crece en la misma proporción sin que llegue ni un mensaje de más.

// Un buzon acotado no es una optimizacion: es la declaracion
// de cuanta desincronia estas dispuesto a tolerar antes de avisar.
type Politica = 'rechazar' | 'descartar-viejo' | 'frenar-emisor'

function buzonAcotado(capacidad: number, politica: Politica) {
  const cola: Mensaje[] = []
  return {
    depositar(mensaje: Mensaje): 'aceptado' | 'rechazado' {
      if (cola.length < capacidad) {
        cola.push(mensaje)
        return 'aceptado'
      }
      if (politica === 'descartar-viejo') {
        cola.shift()
        cola.push(mensaje)
        return 'aceptado'
      }
      return 'rechazado' // frenar-emisor se traduce en reintento del origen
    },
    profundidad: () => cola.length, // la senal que hay que exportar
  }
}

Bloquear al emisor merece un comentario aparte porque es la única política que propaga la información hacia atrás en la cadena, y propagar hacia atrás es la definición misma de contrapresión. El precio es que el envío deja de ser asíncrono puro y el emisor recupera un acoplamiento temporal con el receptor, que es justo lo que el modelo quería evitar. Ese es el trueque de fondo entre actores y modelos de cita síncrona: los primeros compran desacoplamiento y tienen que reconstruir la regulación de flujo; los segundos la traen puesta y pagan con acoplamiento. No existe la tercera opción, y todo sistema de streaming reactivo que hayas usado es una elaboración de esta misma tensión.