Lectura / 04 · 6 min
Intuición de concurrencia estructurada
Razonar sobre el trabajo concurrente a partir de su resultado y su tiempo de vida.
Quién espera a quién
Lanzar dos tareas es sólo una parte del problema. También necesitás decidir qué resultado espera el padre, qué ocurre si una tarea falla y quién se ocupa del trabajo restante cuando el padre termina. La concurrencia estructurada da una relación a esos tiempos de vida.
Effect.all combina resultados de una colección. Que el combinador reciba varias operaciones no basta para concluir que corren en paralelo: la concurrencia se configura. Sin esa opción, Effect.all corre sus operaciones en secuencia. Por eso el preset all-success de este curso pide concurrency: 'unbounded' de forma explícita.
Una carrera por el éxito
Effect.race busca un primer éxito y se ocupa de interrumpir al perdedor. Ese contrato es distinto de elegir la primera finalización sin considerar si tuvo éxito. No conviene inferir tiempos de producción a partir de una carrera de ejemplo.
El lab usa tareas y demoras controladas. Parte de su traza es un resumen didáctico construido por el motor, no un profiler de fibras. El valor final muestra la ejecución real; los rótulos ayudan a leerla, sin prometer todos los eventos internos.
La vida del recurso también importa
Cancelar trabajo no debería dejar recursos abiertos. El último lab conecta esta idea con Scope: registra finalizadores y verifica que se ejecutan tanto después del éxito como después de un fallo.
Como ejercicio, dibujá una solicitud que consulta dos servicios. Marcá qué resultado necesita el usuario y qué debería pasar con la segunda consulta si la primera vuelve innecesaria la espera. Después elegí la composición; el nombre del combinador viene después de la decisión.
Material comunitario para Effect 4 RC. Contrastá la API con la documentación oficial de la versión que uses.