En esta entrada de blog técnica, Matt Massicotte explora el propósito de los actores sin estado en el modelo de concurrencia de Swift. Comienza con una pregunta provocadora: si el papel de un actor es proteger el estado mutable, ¿qué utilidad tiene un actor sin estado? A través de varios ejemplos, argumenta que los actores sin estado pueden servir a propósitos válidos cuando se utilizan intencionalmente. El primer ejemplo es un actor NetworkClient que no tiene propiedades almacenadas pero obtiene conformidad automática con Sendable y asegura que su trabajo sincrónico (como la decodificación JSON) nunca se ejecute en el hilo principal. Sin embargo, esto conlleva compensaciones: los actores imponen la ejecución serial de bloques sincrónicos, lo que puede limitar la concurrencia, y pueden ser difíciles de integrar con protocolos. Contrasta esto con una estructura que utiliza funciones @concurrent que evitan esas limitaciones. A continuación, examina el patrón BackgroundActor, un actor global creado para ejecutar tareas en segundo plano, y advierte sobre su naturaleza serial y el efecto viral de las anotaciones de actor globales. Se presentan actores de ejecutor personalizados como una herramienta poderosa para conectar la concurrencia de Swift con colas de despacho, citando ejemplos con AVFoundation y DispatchSerialQueue. Finalmente, Massicotte analiza el sistema de archivos como estado externo al que un actor puede serializar el acceso, a pesar de ser invisible para el compilador. Concluye que los actores sin estado no son inherentemente inútiles, pero requieren una justificación clara para evitar complicar innecesariamente los diseños.
Cuando un Actor No Tiene Estado: Diseño Intencional o Uso Equívoco?
