Preguntas guía
¿Qué garantiza el protocolo Sendable al compilador sobre un tipo?
Sendable es un tipo de dato que le dice a un compilador que es "thread-safe", y se puede transmitir entre dominios de aislamiento de forma segura (sin introducir un "data-race").
¿Por qué una clase no-final no puede conformar Sendable de forma directa?
Una clase no-final puede tener sub-clases que introduzcan cambios inseguros, por lo que no se puede asegurar que sea "thread-safe".
Así mismo, a pesar de que una clase no-final pueda ser inmutable o tener miembros Sendable, puede ser que una sub-clase agregue miembros que no sean Sendable.
Se puede usar @unchecked Sendable en clases no-finales, sin embargo, esto implica que el desarrollador debe garantizar que la clase es "thread-safe", incluyendo a todas las sub-clases - Debido al inmenso y delicado trabajo que esto representa, no es recomendable.
¿Qué condición debe cumplirse para que una propiedad var en una clase sea compatible con Sendable?
Para que una propiedad var sea compatible con Sendable, debe ser modificada con un "lock".
¿Qué entidades de Swift se pueden marcar como Sendable?
- Tipos-por-referencia y clases finales sin estado mutable.
- Tipos-por-referencia y clases finales que manejan el acceso a su estado internamente (con "locks").
-
Tipos-por-valor como
structoenum. -
Funciones o closures marcadas con
@Sendable.
¿Por qué la conformancia a Sendable debe declararse en el mismo archivo fuente donde se define el tipo?
Sendable necesita ver todas las propiedades almacenadas para verificar que cierto tipo de dato puede ser transmitido de forma segura entre dominios de datos.
--
Compresión profunda
¿Qué diferencia hay entre Sendable y @unchecked Sendable, y cuándo se justifica usar el segundo?
Sendable significa que se garantiza que un tipo de dato es seguro para transmitirse entre dominios de aislamiento.
Conformar Sendable solamente, es una especie de contrato que indica que el compilador garantiza que el dato es "thread-safe". Por otro lado, usar @unchecked Sendable implica que el dato es "thread-safe", pero que no es garantizado por el compilador, sino por el desarrollador.
Se justifica usar @unchecked Sendable en una clase no-final, con miembros mutables por medio de "locks".
¿Cómo afecta el hecho de que una clase sea un reference type a su elegibilidad para Sendable?
Debido a que un objeto es reference-type, este puede ser modificado desde varios hilos. Si tiene miembros mutables, entonces no se puede garantizar que sea seguro para transmitirse entre dominios de aislamiento. Por esta razón, en caso de ser Sendable, debe ponerse @unchecked para indicar que es el desarrollador quien asegura que es seguro y no el compilador.
Por otro lado, los miembros mutables deben ser modificados a través de "locks" e, idealmente, la clase debería ser final.
Retención
Sin releer el artículo, ¿puedes enumerar al menos cuatro tipos de entidades Swift que pueden marcarse como Sendable?
- Funciones y closures marcados con
@Sendable. - Tipos de valor
structyenum. - Tipos de referencia (no-
finalyfinal) con datos inmutables o protegidos con locks.
¿Qué problema concreto introduce un var no protegido en una clase que intenta conformar Sendable?
La variable puede ser modificada desde varios hilos simultáneamente.
Evaluación crítica
¿Por qué el artículo desaconseja el uso de @unchecked Sendable y qué alternativas propone?
El artículo propone usar composición, clases finales o value-types.
Top comments (0)