Concurrencia de Swift - SDK de Swift

Advertencias sobre la concurrencia de Realm

A medida que implementa funciones de concurrencia en su aplicación, tenga en cuenta esta advertencia sobre el modelo de subprocesos de Realm y los comportamientos de subprocesos de concurrencia de Swift.

API asíncronas/en espera

Muchas API de Realm Swift que trabajan con una aplicación de Atlas App Services o un reino sincronizado son compatibles con la sintaxis async/await de Swift. Para ver ejemplos, consulte:

• Inicio de sesión asíncrono/en espera

• Administrar usuarios de correo electrónico y contraseña

• Vincular identidades de usuario - Async/Await

• Abrir un reino sincronizado o un reino local

• Esperar notificaciones de otro actor

• Administrar suscripciones de sincronización flexible

• Llamada asíncrona/en espera a una función sin servidor

• Consulta asíncrona/en espera MongoDB

• Operaciones CRUD asíncronas/en espera

Si tiene solicitudes de funciones específicas relacionadas con las API async/await de Swift, consulte el motor de comentarios de MongoDB para Realm. El equipo del SDK de Swift de Realm planea seguir desarrollando funciones relacionadas con la concurrencia basándose en los comentarios de la comunidad y la evolución de la concurrencia en Swift.

Tareas y grupos de tareas

La concurrencia de Swift proporciona API para gestionar tareas y grupos de tareas. La documentación de concurrencia de Swift define una tarea como una unidad de trabajo que puede ejecutarse asincrónicamente como parte de su programa. Tarea permite definir específicamente una unidad de trabajo asincrónico. Grupo de tareas permite definir un conjunto de tareas que se ejecutan como una unidad dentro del grupo de tareas principal.

Las tareas y los grupos de tareas permiten asignar el hilo a otras tareas importantes o cancelar una tarea de larga duración que podría bloquear otras operaciones. Para obtener estas ventajas, podrías considerar usar tareas y grupos de tareas para gestionar las escrituras en el dominio en segundo plano.

Sin embargo, las restricciones de hilo descritas en "Suspender la ejecución con Await" se aplican en el contexto de la tarea. Si la tarea contiene await puntos, el código posterior podría ejecutarse o reanudarse en un hilo diferente e infringir el confinamiento de hilo de Realm.

Debes anotar las funciones que ejecutas en un contexto de tarea con @MainActor para garantizar que el código que accede a Realm solo se ejecute en el hilo principal. Esto anula algunas de las ventajas de usar tareas y puede significar que no sea una buena opción de diseño para aplicaciones que usan Realm, a menos que las uses únicamente para actividades de red, como la gestión de usuarios.

Aislamiento del actor

El aislamiento de actores proporciona la percepción de limitar el acceso al Reino a un actor dedicado y, por lo tanto, parece una forma segura de gestionar el acceso al Reino en un contexto asincrónico.

Sin embargo, actualmente no se admite el uso de Realm en una función asíncrona que no sea@MainActor.

En Swift 5.6, esto solía funcionar por coincidencia. La ejecución después de un await continuaba en el hilo donde se ejecutaba el objeto esperado. Usar await Realm() en una función asíncrona hacía que el código posterior se ejecutara en el hilo principal hasta la siguiente llamada a una función aislada del actor.

Swift 5.7, en cambio, salta entre subprocesos al cambiar los contextos de aislamiento de los actores. Una función asíncrona no aislada siempre se ejecuta en un subproceso en segundo plano.

Si tienes código que utiliza await Realm() y funciona en la versión 5.6, marcar la función como @MainActor hará que funcione con Swift 5.7. Funcionará como lo hizo - sin querer - en 5.6.

Errores relacionados con el código de concurrencia

Con mayor frecuencia, el error que ve relacionado con el acceso a Realm a través del código de concurrencia es Realm accessed from incorrect thread.. Esto se debe a los problemas de aislamiento de subprocesos que se describen en esta página.

Para evitar problemas relacionados con el threading en el código que utiliza funcionalidades de concurrencia de Swift:

• Actualice a una versión del SDK de Realm Swift que admita dominios aislados por actores y úsela como alternativa a la gestión manual de subprocesos. Para obtener más información, consulte Usar Realm con actores - SDK de Swift.

• No cambie los contextos de ejecución al acceder a un dominio. Si abre un dominio en el hilo principal para proporcionar datos a su interfaz de usuario, anote con @MainActor las funciones posteriores donde acceda al dominio de forma asíncrona para garantizar que siempre se ejecuten en el hilo principal. Recuerde que await marca un punto de suspensión que podría cambiar a otro hilo.

• Las aplicaciones que no usan dominios aislados por actores pueden usar la writeAsync API para realizar una escritura en segundo plano. Esto gestiona el acceso al dominio de forma segura para subprocesos, sin necesidad de escribir código especializado. Esta API especial externaliza aspectos del proceso de escritura (cuando es seguro hacerlo) para ejecutarse en un contexto asíncrono. A menos que escriba en un dominio aislado por actores, no utilice este método con async/await la sintaxis de Swift. Úselo sincrónicamente en su código. Como alternativa, puede usar la asyncWrite API con la sintaxis de Swift async/await al esperar escrituras en dominios asíncronos.

• Si desea escribir código concurrente explícito que no esté aislado de actores y donde el acceso a un reino se realice de forma segura para subprocesos, puede pasar instancias explícitamente entre subprocesos cuando corresponda para evitar fallos relacionados con los subprocesos. Esto requiere un buen conocimiento del modelo de subprocesos de Realm, así como la consideración de los comportamientos de subprocesos concurrentes de Swift.

Tipos enviables, no enviables y confinados a subprocesos

La API pública del SDK Swift de Realm contiene tipos que se dividen en tres categorías amplias:

• Enviable

• No se puede enviar y no está confinado en el hilo

• Confinado en hilo

Puedes compartir tipos que no sean Enviables y que no estén confinados entre subprocesos, pero debes sincronizarlos.

Los tipos confinados por subprocesos, a menos que estén congelados, se limitan a un contexto de aislamiento. No se pueden pasar entre estos contextos, ni siquiera con sincronización.