DEV Community: GoyesDev

[SC] nonisolated(nonsending) y @concurrent

GoyesDev — Tue, 28 Apr 2026 22:10:03 +0000

Preguntas

¿Cuál es la diferencia entre el comportamiento anterior y el nuevo de las funciones `nonisolated async` a partir de Swift 6.2?

Antes de Swift 6.2, las funciones nonisolated async se ejecutaban de forma independiente, sin heredar el contexto de ejecución. Esto significa que cada función nonisolated async es una sub-tarea que decide por sí misma dónde ejecutarse. Si se anota con @MainActor o algún @globalActor, entonces se va a ejecutar en el executor de dicho actor. En caso contrario, se va a ir a un hilo de segundo plano.

A partir de Swift 6.2 las funciones nonisolated async corren, por defecto, en al actor invocador.

Para rechazar la herencia de dominio de aislamiento, se debe marcar el método específicamente con el atributo @concurrent.

¿Bajo qué circunstancias una tarea (`Task`) puede ejecutarse en el hilo principal en lugar de en un hilo en segundo plano?

Una Task se puede ejecutar en el hilo principal si está marcada con @MainActor, o si fue invocada por una tarea marcada con @MainActor en Swift 6.2.

¿Para qué sirve el atributo `@concurrent` y cuándo se debe usar?

@concurrent sirve para que un método nonisolated async NO herede el contexto del método invocador.

¿Qué problema resuelve `nonisolated(nonsending)` y cuándo es apropiado aplicarlo?

En caso de que la propiedad NonisolatedNonsendingByDefault esté puesta en NO, puede aparecer un error como Sending value of non-Sendable type ‘MyType’ risks causing data races.

Este error aparece porque Swift asume que, sin nonisolated(nonsending), la función va a correr en un dominio de aislamiento diferente al del llamador. Cuando eso pasa, Swift necesita enviar el valor (selfu otros parámetros) de un dominio a otro - y si el tipo no esSendable`, el compilador dice: "Peligro, datarace!".

nonisolated(nonsending) le dice al compilador: "Esta función va a heredar el dominio de aislamiento del llamador, así que no hay ningún envío entre dominios".

Si no hay envío, no hay riesgo de data race.

nonisolated(nonsending) no es una solución mágica universal. Funciona solo cuando de verdad estoy de acuerdo con que la función bloquee el actor del llamador.

Si la función hace algo pesado, usar nonisolated(nonsending) podría bloquear el hilo en cuestión. En ese caso, la solución correcta sería hacer el tipo Sendable.

¿Cómo se puede verificar en qué hilo se está ejecutando una tarea durante el desarrollo?

Usar Thread.current. Teniendo en cuenta que posiblemente sea necesario usar la extensión:

swift extension Thread { public static var currentThread: Thread { return Thread.current } }

Por otro lado, siempre se puede poner un punto de quiebre para mirar en qué hilo se está parado.

¿cómo explica el autor que el actor de llamada puede influir en el hilo donde se ejecuta una tarea?

El actor del llamador determina dónde empieza la tarea y a dónde regresa después de cada punto de suspensión.

En el ejemplo del artículo:

`swift
@MainActor
private func updateUI() {
Task {
print("Starting on the main thread")
await someBackgroundTask()
print("Resuming on the main thread")
}
}

private func someBackgroundTask() async {
print("Background task on thread: 8")
}
`

someBackgroundTask() corre en el hilo 8. No obstante, la primera línea del Task de updateUI() corre en el hilo 1, y después de la suspensión de await someBackgroundTask()`, el trabajo regresa al hilo 1.

¿Qué cambio introduce SE-461 y cuál es la justificación filosófica que da el autor al citarlo?

SE-461: Run nonisolated async functions on the caller’s actor by default hace que las funciones nonisolated async hereden el contexto del método invocador. En caso de no querer que esto pase, entonces hay que marcar con el atributo @concurrent.

El comportamiento anterior de las funciones nonisolated async sacrificaba usabilidad innecesariamente para proteger la responsividad del hilo principal.

Recitación

¿puedes explicar con tus palabras qué ocurre cuando una función nonisolated es llamada desde un contexto `@MainActor` en Swift 6.2 con el nuevo flag activado?

¿Cuándo elegirías `@concurrent` y cuándo `nonisolated(nonsending)`? ¿Puedes describir un caso de uso para cada uno?

¿Cómo habilitarías el nuevo comportamiento de `NonisolatedNonsendingByDefault` en un proyecto de Xcode?

Revisión

¿Cómo se relacionan los conceptos de actor isolation, `@MainActor` y el pool cooperativo de hilos de Swift?

¿Por qué el autor advierte que este cambio puede confundir a quienes ya conocían Swift Concurrency antes de la versión 6.2?

¿Qué implicaciones de rendimiento puede tener el nuevo comportamiento por defecto si no se usa `@concurrent` donde corresponde?

¿En qué se diferencia el error de compilación "Sending value of non-Sendable type" del problema que resuelve `nonisolated(nonsending)`?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Puntos de suspensión de una Task

GoyesDev — Tue, 28 Apr 2026 16:33:05 +0000

Preguntas

¿Qué es exactamente un punto de suspensión en una tarea de Swift?

Un punto de suspensión es un momento donde una Task puede pausar su ejecución para permitir que otro trabajo pueda ejecutarse.

Cada uso de await es un punto de suspensión potencial.

¿Por qué no todo `await` garantiza una suspensión real?

Si la tarea esperada (await) puede ser completada de forma síncrona, la tarea de origen no se suspende sino que seguirá ejecutando inmediatamente. Esto puede ocurrir cuando el método asíncrono pertenece al mismo dominio de aislamiento. await simplemente marca un posible punto de suspensión, no uno garantizado.

¿Qué es la reentrada de actores y cuándo ocurre?

Un actor garantiza que solo una Task puede acceder a su estado aislado a la vez. Sin embargo, si una tarea encuentra un punto de suspensión dentro del actor, existe la posibilidad de que otra tarea empiece a trabajar con el actor antes de que la primera termine.

¿Qué riesgos concretos introduce un punto de suspensión dentro de un actor?

Todo estado mutable que asume una ejecución ininterrumpida podría comportarse de forma incorrecta si la tarea es suspendida. Esto puede derivar en un estado inconsistente porque podría solaparse con otra tarea que podría mutar el estado del actor antes de que la primera termine.

¿Cómo se puede evitar el comportamiento inesperado por reentrada?

Evitar modificar el estado mutable de un actor después de un punto de suspensión.
Guardar información importante para el desarrollo del método en variables locales.

¿Qué cambia exactamente en la versión corregida del método `deposit`?

El punto de suspensión aparece después de modificar el estado del actor. Todas las modificaciones al estado del actor se agrupan antes del await.

// Antes
func deposit(amount: Int) async {
  balance += amount
  print("[\(balance)] Deposited \(amount), balance is now \(balance)")

  await logTransaction(amount) // ⚠️ Suspension point

  balance += 10 // bonus after logging
  print("[\(balance)] Applied bonus, balance is now \(balance)")
}

// Después
func deposit(amount: Int) async {
  balance += amount
  print("[\(balance)] Deposited \(amount), balance is now \(balance)")

  balance += 10 // bonus after logging
  print("[\(balance)] Applied bonus, balance is now \(balance)")
  await logTransaction(amount) // ⚠️ Suspension point
}

Recitación / comprensión

Explica con tus propias palabras por qué el balance pasa de 100 → 200 en lugar de 100 → 110.

¿Cuál es la diferencia entre un punto de suspensión posible y uno garantizado?

¿Por qué mover el `await` al final del método soluciona el problema de reentrada?

Revisión y síntesis

¿Cuál es la regla práctica más importante para mutar el estado de un actor de forma segura?

¿En qué situaciones de tu propio código deberías revisar dónde caen los puntos de suspensión?

¿Qué tema cubre la siguiente lección y cómo se relaciona con lo aprendido aquí?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Deshacerse de la mentalidad de hilos

GoyesDev — Tue, 28 Apr 2026 15:36:04 +0000

Preguntas

¿Por qué Swift Concurrency quiere que dejes de controlar manualmente los hilos?

Controlar manualmente los hilos trae los siguientes costos:

Costo elevado en memoria (stack de cada thread)
Intercambio de contextos innecesariamente alto (más trabajo para los procesadores)
problemas de inversión de prioridad.

Debido a los problemas anteriores, Swift Concurrency nos invita a dejar que el framework se encargue del manejo de hilos.

¿Qué es un dominio de aislamiento y cómo reemplaza el concepto de hilo?

Un dominio de aislamiento es una región o contexto al que pertenece un fragmento de código. Este contexto determina cómo ejecutar el código de forma segura y sin carreras de datos.

El cambio de paradigma consiste en que ahora se declara a qué dominio pertenece el código y Swift se encarga de ejecutarlo de forma segura, en el hilo que considere más eficiente.

¿Qué papel juegan los actores (`actors`) en Swift Concurrency?

Todo el código definido dentro un actor pertenece a su dominio de aislamiento y es ejecutado por un executor independiente, lo que garantiza que el código se ejecute de forma serial dentro del actor, evitando acceso concurrentes a su estado interno.

¿Cómo se le dan "pistas" al sistema sobre la prioridad de una tarea?

La "prioridad" de una tarea no establece directamente el orden de ejecución del código, sino que sugiere al runtime el nivel de importancia que tiene el bloque a ejecutar.

Sin embargo, puede darse el caso que tenga una tarea de prioridad alta que esté esperando a que una tarea de prioridad baja termine. Por esto se dice que la "prioridad" de una tarea es más bien una sugerencia.

¿Por qué una tarea de alta prioridad no garantiza ejecución inmediata?

La prioridad de una "tarea" es una sugerencia para el runtime. No se está asignando la tarea a un hilo, sino que se está indicando la naturaleza del trabajo a realizar.

¿Qué problema resuelve la conformancia con `Sendable`?

Un dato Sendable es seguro para cruzar dominios de aislamiento. Como Swift puede mover código entre hilos y no se puede predecir en cuál reanudará, es necesario garantizar que los datos compartidos entre dominios son seguros de transferir.

Según el artículo, ¿cuáles son los tres problemas que evita dejar que Swift gestione los hilos?

Uso excesivo de memoria (para guardar el contexto)
Uso elevado de procesador (para cambiar de contexto)
Inversión de prioridad

En el ejemplo de código, ¿por qué la "`Task` 1" aparece ejecutándose en hilos distintos al inicio y al reanudarse?

La creación de una Task no garantiza la ejecución en un hilo específico. En el ejemplo, ante la aparición del punto de suspensión, la Task 1 cambió de hilo.

Recitación

Con tus propias palabras, ¿qué significa pensar en dominios de aislamiento en lugar de hilos?

Explica por qué Sendable se vuelve necesario precisamente porque Swift puede mover trabajo entre hilos.

Revisión

¿Qué cambio mental fundamental propone el artículo respecto a cómo escribir código concurrente en Swift?

¿Cómo conectan entre sí los conceptos de actores, prioridades y Sendable dentro del modelo de Swift Concurrency?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Relación entre Hilos y Tasks

GoyesDev — Tue, 28 Apr 2026 11:47:54 +0000

Preguntas

¿Qué es exactamente un hilo y por qué tiene un alto costo de creación y cambio de contexto?

Un hilo es un recurso, manejado por el sistema operativo, que ejecuta una secuencia de instrucciones. Crear hilos y cambiar el contexto entre ellos es una operación muy costosa.

Cada hilo requiere su propia pila de memoria (stack) y el cambio de contexto obliga al CPU a guardar y restaurar el estado completo del hilo (registros, puntero de instrucción, etc).

¿Por qué Swift Concurrency no garantiza en qué hilo se ejecutará una función asíncrona?

Swift Concurrency dispone de un pool global concurrente de hilos (tantos como el número de procesadores del dispositivo).

Para optimizar el uso de hilos, se despacha una Task en cualquier hilo disponible. Cuando hay un punto de suspensión (await), el runtime de Swift Concurrency cede el hilo a cualquier otra tarea. Luego, cuando la Task recupera el contexto, el runtime de SC le asigna cualquier hilo disponible - que puede ser el que tenía inicialmente, pero no está garantizado, porque el sistema pudo haberlo asignado a otra Task.

Aquí quien limita los hilos no es el sistema operativo sino el framework Swift Concurrency. El sistema operativo podría crear muchos más hilos (como lo hacía GCD). Es una decisión de diseño del framework, no una restricción del sistema operativo.

¿Qué ocurre exactamente cuando una tarea llega a un punto de suspensión con `await`?

El sistema suspende la Task y devuelve el hilo al pool global de hilos - Lo que significa que está disponible para que cualquier otra Task lo tome.

¿Cómo funciona el `cooperative thread pool` y por qué limita los hilos al número de núcleos de CPU?

Para no tener "thread explosion" y así degradar el desempeño de la aplicación debido al cambio de contexto entre hilos y posibles problemas de inversión de prioridades, el sistema operativo limita la creación de hilos al número de núcleos del procesador.

El "cooperative thread pool" son todos los hilos disponibles para ser usados por las distintas Tasks.

¿Qué es el `thread explosion` y cómo lo evita Swift Concurrency?

"thread explosion" ocurre porque se crean demasiados hilos y aparecen bloqueos que provocan:

Desperdicio de memoria debido a los hilos detenidos.
Intercambio excesivo de contexto (que reduce la eficiencia del procesador)
Problemas de inversión de prioridad.

¿Por qué tener menos hilos no reduce el rendimiento comparado con GCD?

Aunque es contraintuitivo, el intercambio innecesario de contexto y el desperdicio de memoria son problemas que se reducen al tener menos hilos.

¿Qué demuestra el ejemplo de código con `ThreadingDemonstrator` sobre la relación entre tareas e hilos?

private struct ThreadingDemonstrator {
  private func firstTask() async throws {
    print("Task 1 started on thread: \(Thread.currentThread)")
    try await Task.sleep(for: .seconds(2))
    print("Task 1 resumed on thread: \(Thread.currentThread)")
  }

  private func secondTask() async {
    print("Task 2 started on thread: \(Thread.currentThread)")
  }

  func demonstrate() {
    Task {
      try await firstTask()
    }
    Task {
      await secondTask()
    }
  }
}

struct ThreadingDemonstratorTests {
  @Test
  func execute() async throws {
    let sut = ThreadingDemonstrator()
    sut.demonstrate()

    try await Task.sleep(for: .seconds(3))
  }
}

No se puede garantizar el orden de ejecución de las tareas firstTask y secondTask. Para hacerlo hay que usar await.
Cuando se asigna un hilo a una tarea y esta se suspende, no se puede garantizar que lo recupere una vez se reanude.

¿Por qué la tarea 1 puede reanudarse en un hilo diferente al que inició?

Cuando se suspende la tarea 1, cede ("yield") el hilo que tenía y el sistema operativo es libre de asignárselo a cualquier otra tarea.

¿Qué diferencia introduce el modo Swift 6 respecto a acceder a `Thread.current` y cómo se resuelve?

Usar Thread.current desde un contexto asíncrono arrojará el error de compilación: Class property 'current' is unavailable from asynchronous contexts; Thread.current cannot be used from async contexts..

La solución fue envolver el llamado de Thread.current en un método (variable computada) nonisolated static:

extension Thread {
  public nonisolated static var currentThread: Thread {
    return Thread.current
  }
}

Recitación

Explica con tus propias palabras qué significa "ceder el hilo" (yielding the thread) cuando se usa await.

¿Cuáles son los tres conceptos erróneos sobre Swift Concurrency que menciona el artículo? ¿Puedes refutarlos?

¿Qué tres consecuencias negativas produce el thread explosion en GCD?

¿Cómo describirías el cooperative thread pool a alguien sin experiencia en concurrencia?

Revisión

¿En qué situaciones concretas deberías seguir pensando en si algo corre en el hilo principal o en un hilo en segundo plano?

Si Swift Concurrency ya gestiona los hilos automáticamente, ¿qué valor tiene entender cómo funcionan internamente?

¿Cómo cambiaría tu forma de escribir código asíncrono ahora que sabes que `await` no bloquea el hilo?

¿Qué preguntas te quedan sin responder sobre el `@MainActor` y cómo encaja con lo aprendido aquí?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] ¿Cuándo usar AsyncStream en lugar de AsyncSequence?

GoyesDev — Tue, 28 Apr 2026 10:59:43 +0000

Preguntas

¿Cuándo debería usar `AsyncSequence` en lugar de `AsyncStream`, y viceversa?

AsyncSequence es la abstracción a la que debería acoplarme, mientras que AsyncStream es una implementación concreta de AsyncSequence que puedo utilizar para emitir eventos.

¿Qué ventajas ofrece `AsyncStream` para casos de uso comunes?

Se puede usar directamente esta implementación concreta, definiendo el closure que recibe un continuation.

El API de AsyncStream es fácil de recordar y escribir, y especialmente útil para crear puentes entre delegados, llamados a closures y emisión manual de eventos.

¿Cómo se relacionan `AsyncSequence` y `AsyncStream` entre sí?

AsyncStream conforma AsyncSequence.

¿Qué ejemplo concreto usa el artículo para ilustrar el puente de delegates con `AsyncThrowingStream`?

En el artículo se creó un LocationMonitor que funciona como delegado (CLLocationManagerDelegate) de un CLLocationManager. Este LocationMonitor tenía un atributo llamado stream de tipo AsyncThrowingStream<CLLocation, Error>, manejado con un continuation de tipo AsyncThrowingStream<CLLocation, Error>.Continuation?.

Cada vez que el LocationMonitor recibía un evento como delegado de LocationMonitor, emitía un evento al stream a través del continuation con yield(_:), y finish(throwing:).

¿Cómo funciona el método `AsyncStream.init(unfolding:oncancel:)` en el ejemplo del servicio de `ping`?

AsyncStream.init(unfolding:onCancel:) recibe un closure asíncrono que produce elementos (unfolding) y otro opcional que se maneja la cancelación (oncancel).

¿Por qué el artículo compara `AsyncSequence` con el protocolo `Sequence` en Swift?

AsyncSequence es la versión asíncrona de Sequence. Además, el artículo menciona que muy pocas veces implementamos el protocolo Sequence, sino que son mayormente otros tipos de datos del SDK de iOS que lo conforman - Básicamente nosotros como desarrolladores tendríamos la misma relación con AsyncSequence.

Recitación / comprensión

Sin releer, ¿puedes explicar con tus palabras cuándo elegirías `AsyncStream` sobre `AsyncSequence`?

¿Qué hace la `continuation` en el ejemplo de `LocationMonitor` y por qué es clave?

¿Qué APIs estándar de Apple mencionadas en el artículo conforman `AsyncSequence`?

Repaso final

¿Cuál es la conclusión principal del artículo sobre cuál opción usar en la mayoría de proyectos reales?

¿Qué limitación menciona el artículo sobre el ejemplo de `LocationMonitor`?

¿En qué escenarios reales, mencionados explícitamente, tiene más sentido usar `AsyncStream`?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] AsyncStream y AsyncThrowingStream

GoyesDev — Tue, 28 Apr 2026 01:33:44 +0000

Preguntas

¿Qué es un `AsyncStream` y en qué se diferencia de un `AsyncThrowingStream`?

Un AsyncStream es un AsyncSequence que puede emitir eventos de progreso y fin con base en un AsyncStream.Continuation.

Es muy parecido a un Publisher de Combine, con la diferencia que solo admite un suscriptor.

AsyncThrowingStream es la versión que arroja error de AsyncStream.

¿Por qué podría querer reemplazar un closure de progreso/completación con un `AsyncThrowingStream`?

Facilita la integración del API de async/await en lugar de una integración basada en closures. Además, AsyncStream permite poder iterar con for try await en lugar de anidar closures, lo que hace el flujo más lineal y legible.

¿Qué sucede si no se llama a `continuation.finish()` al terminar un `stream`?

La implementación se va a quedar colgada sin terminar. El código que itera el stream con for try await nunca avanza más allá del loop porque el stream nunca emite el evento de terminación.

¿Qué son las `buffer policies` y cuándo tendría sentido usar cada una?

Las "buffer policies" define qué hacer con los valores emitidos cuando no hay ningún consjmidor leyendo aún. Es decir: regulan el buffer previo a la lecutra, no a la entrega en tiempo real. En el artículo se mencionan:

AsyncStream.Continuation.BufferingPolicy.unbounded: El suscriptor recibe todos los eventos pasados emitidos por el AsyncStream antes de la suscripción.
AsyncStream.Continuation.BufferingPolicy.bufferingOldest(_:): El suscriptor recibe los primeros (oldest) n eventos emitidos por el AsyncStream.
AsyncStream.Continuation.BufferingPolicy.bufferingNewest(_:): El suscriptor recibe los últimos (newest) n eventos emitidos por el AsyncStream. En el artículo ponen de ejemplo que al usar bufferingnewest(0), se ignoran todos los eventos pasados emitidos por el AsyncStream.

¿En qué se diferencia un `AsyncStream` de un `publisher` de `Combine`?

El Publisher de Combine puede tener varios suscriptores. El AsyncStream solo puede tener uno.

¿Cómo se usa el `continuation` para enviar valores, manejar errores y terminar el `stream`?

Sobre el continuation se pueden usar los siguientes métodos:

yield(with:): Para emitir un elemento de tipo Result<Element,Never> en unAsyncStream`.
yield(with:): Para emitir un elemento de tipo Result<Element,Failure> en un AsyncThrowingStream`.
finish(): Para cerrar el Stream sin emitir error.
finish(throwing:): Para cerrar el Stream emitiendo un error
onTermination: Suscribe un closure para ejecutar algún trabajo cuando termina el stream. Este sirve para hacer labores de limpieza o depuración.

¿Qué hace el `callback onTermination` y para qué casos de uso es útil?

Suscribe un closure para ejecutar algún trabajo cuando termina el stream. Este sirve para hacer labores de limpieza o depuración.

¿Cómo y cuándo se cancela un stream, y qué efecto tiene la cancelación?

Un Stream se cancela cuando el contexto asíncrono que lo envuelve es cancelado (e.g. Task.cancel()).

El stream se termina (no en error, ni en success), sino que se invoca onTermination con la causa (i.e. "termination reason: cancelled")

No hay forma de cancelar el stream explícitamente, solo de forma indirectamente a través del Task que lo envuelve.

¿Por qué no es seguro tener múltiples consumidores de un mismo `AsyncStream`?

Como solo puede tener un suscriptor, no se sabe a cuál le va a entregar el valor. Los valroes se reparten entre los consumidores en lugar de duplicarse - Cada valor lo recibe uno solo, de forma impredecible.

Recordar sin mirar el texto

Explica con tus propias palabras el ciclo de vida de un `AsyncThrowingStream`, desde su creación hasta su terminación.

¿Cuáles son las tres razones posibles por las que un stream puede terminar y cómo se reporta cada una?

Sin mirar el código, describe cómo transformarías el `FileDownloader` basado en closures a uno basado en `AsyncThrowingStream`.

Revisión y conexión de ideas

¿En qué escenarios concretos de tu propio código usarías un `AsyncStream` en lugar de `Combine` o callbacks?

¿Cuál es la limitación más importante de `AsyncStream` mencionada en el artículo y cómo se puede mitigar?

¿Qué errores de programación comunes advierte el artículo y qué estrategias propone para detectarlos?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Trabajando con secuencias asíncronas

GoyesDev — Mon, 27 Apr 2026 23:31:04 +0000

Preguntas

¿Qué es un `AsyncSequence` y en qué se diferencia de un `Sequence` normal?

AsyncSequence es un tipo de dato que provee acceso secuencial e iterativo a una colección de forma asíncrona.

AsyncSequence es un hermano de Sequence que prácticamente puede hacer todo lo que hace Sequence (como contains(_:), map(_:)) con la diferencia que los datos se recorren de forma asíncrona.

¿Qué rol cumplen `AsyncIterator` y el método `next()` dentro de una secuencia asíncrona?

Un tipo de dato que conforme el protocolo AsyncSequence debe definir el método makeAsyncIterator() que devuelve una instancia que conforme el protocolo AsyncIteratorProtocol.

Un AsyncIterator es como un IteratorProtocol con la diferencia que debe recorrer una colección asíncrona a través del método next() async que puede tener puntos de suspensión y, retorna el siguiente valor de la colección o nil si ya terminó el trabajo.

¿Cómo se indica el fin de la iteración en un `AsyncSequence` personalizado?

Se indica el fin de una iteración devolviendo nil. Esto puede ocurrir por dos razones:

se alcanzó el límite configurado
la tarea fue cancelada (Task.isCancelled).

¿Por qué se recomienda usar `AsyncStream` en lugar de implementar `AsyncSequence` directamente?

AsyncStream es más conveniente de configurar que AsyncSequence, porque al usar este último se debe un AsyncIterator y manejar su estado.

¿Qué operadores de `Sequence` están disponibles también para secuencias asíncronas?

Métodos como:

contains(where:) - Tener cuidado que métodos como este esperan a que la secuencia asíncrona termine de emitir elementos y se puede quedar esperando indefinidamente.
map(_:)
filter(_:)

Identifica cómo el protocolo `AsyncSequence` define el acceso a valores sin generarlos por sí mismo.

AsyncSequence se encarga de la construcción del AsyncIteratorProtocol, quien técnicamente es el encargado de generar los elementos en el método next() async.

Analiza cómo la cancelación con `Task.isCancelled` interactúa con el ciclo de vida de la secuencia.

Entro del contexto de next() async es de vital importancia verificar que la tarea no haya sido cancelada con Task.isCancelled (sin esta verificación, la secuencia seguiría emitiendo valores a pesar de que la tarea hubiera sido cancelada). Si lo fue, entonces retornar nil.

Recitación

Explica con tus palabras qué hace el método `next()` en el ejemplo `Counter`.

¿Cómo se usa `for await` para iterar sobre un `AsyncSequence` y por qué es necesario el `await`?

Menciona al menos dos operadores que se pueden aplicar sobre una secuencia asíncrona y describe su efecto.

¿Qué ocurre si una secuencia asíncrona nunca termina y usas un método como `contains`?

Revisión

¿En qué situaciones reales tiene sentido usar un `AsyncSequence` en lugar de un `array` estático?

¿Por qué el artículo dice que un `AsyncSequence` "prepara para valores asíncronos" aunque no siempre los envíe de forma asíncrona?

¿Qué relación existe entre los task groups vistos en lecciones anteriores y el concepto de `AsyncSequence`?

Después de leer este módulo, ¿qué preguntas tienes sobre `AsyncStream`, el siguiente tema?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Usando un Mutex como alternativa a los actores

GoyesDev — Mon, 27 Apr 2026 21:29:37 +0000

Preguntas

¿Qué es un `Mutex` y en qué se diferencia de un `Lock`?

Un Mutex es un tipo de Lock del framework Synchronization usado para sincronizar accesos a una variable a través del método withLock(_:).

El método withLock es equivalente a hacer:

mutex.lock()
defer {
  mutex.unlock()
}
return try body(&value)

Observar que value es un valor inout, que se devuelve el valor generado por try body(&value) y que puede arrojar un error.

La diferencia importante entre Mutex y Lock es que usando Lock, el tipo de dato no es Sendable (tendría que marcarse con @unchecked Sendable). En cambio, Mutex sí es Sendable porque encapsula su valor internamente y controla todo acceso a él.

¿Por qué Apple introdujo un `Mutex` si ya existen los actores en Swift Concurrency?

Mutex es una aproximación bloqueante síncrona que, en ocasiones, puede servir en lugar de un actor asíncrono. Usar el actor asíncrono implica un "overhead" de "scheduling", además de que el invocador debe estar en un contexto síncrono.

El Mutex es útil cuando el trabajo protegido es breve y el bloqueo es más eficiente que suspender y reanudar una tarea.

¿Desde qué versiones de iOS y macOS está disponible el framework `Synchronization`?

iOS 18 y macOS 15.

¿Cómo se usa el método `withLock` y qué tipo de acceso proporciona al valor protegido?

Debido a que el parámetro que recibe withLock es inout, entonces da un acceso por referencia.

withLock se usa pasando un closure que puede modificar el valor protegido y puede retornar algún valor. En el ejemplo del artículo teníamos:

var currentCount: Int {
  count.withLock { currentCount in
    return currentCount
  }
}

func increment() {
  count.withLock { currentCount in
    currentCount += 1
  }
}

¿Cómo permite el `Mutex` trabajar con tipos no-`Sendable` como `NSBezierPath`?

A pesar de que NSBezierPath es no-Sendable, se puede crear un Mutex, constante (let), que envuelva al NSBezierPath y modificar el path protegido.

let path = Mutex<NSBezierPath>(NSBezierPath())

func storeTouch(_ point: NSPoint) {
  path.withLock { path in
    path.move(to: point)
  }
}

¿Qué sucede cuando múltiples hilos intentan adquirir un `Mutex` al mismo tiempo?

Si un hilo trata de tomar el Mutex y este ya fue tomado, entonces el hilo permanece bloqueado hasta que el Mutex sea liberado.

Recapitulación

¿En qué situaciones concretas es preferible usar un `Mutex` en lugar de un actor?

¿Cómo se puede lanzar un error desde dentro del closure `withLock`?

Repaso y reflexión

¿Cuál es la conclusión principal del artículo respecto a la elección entre actores y `Mutex`?

¿Qué ventajas y desventajas tiene cada herramienta según el contexto del proyecto?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Usando Taks inmediatas

GoyesDev — Mon, 27 Apr 2026 21:02:34 +0000

Preguntas guía

¿Cuál es la diferencia fundamental entre `Task` y `Task.immediate` en cuanto a cuándo empieza a ejecutarse el trabajo?

Task.immediate empieza ejecutando de forma síncrona el código definido dentro del bloque de trabajo, hasta que encuentra el primer punto de suspensión real. En este punto, continua con el trabajo fuera del Task.

¿Qué significa exactamente que una tarea inmediata "corre hasta el primer punto de suspensión real"?

El primer punto de suspensión real aparece cuando alguna operación costosa (e.g. I/O, actor ocupado, etc) cause que la tarea tenga que esperar.

Si antes de ese punto hay una salida temprana o un código síncrono simple, Task.immediate puede ejecutarlo como si fuera síncrono (sin cambiar al contexto asíncrono).

¿En qué escenarios concretos tiene sentido usar `Task.immediate` en lugar de un `Task` regular?

Empezar la ejecución de código asíncrono desde un contexto síncrono, preservando el orden.
Necesito cambiar rápidamente parte del estado del actor que va a ser usado después del Task.immediate.
Salir tempranamente del bloque definido en Task.immediate con una condición sencilla.

¿Qué es el `overhang` y por qué es especialmente peligroso en el `MainActor`?

overhang es ejecutar una cantidad significativa de código síncrono en un executor antes del primer punto de suspensión.

Si defino un método como @MainActor, y dentro de Task.immediate empiezo haciendo un trabajo síncrono muy demorado (e.g. que tome 300 milliseconds), esto va a bloquear la interfaz gráfica.

@MainActor
func handleSearchQuery(_ query: String) {
  Task.immediate {
    let results = expensiveLocalSearch(query)
    await updateResults(results)
  }
}

¿Cómo se comporta `Task.immediate { @MainActor in ... }` cuando el `executor` actual no es el `MainActor`?

Cuando se usa Task.immediate { @MainActor in ... } y el executor actual es MainActor, en la práctica es como si tuviéramos código síncrono.

Sin embargo, llamar Task.immediate { @MainActor in ... } desde otro actor va a tener el mismo efecto que Task{ @MainActor in ... } (i.e. como si fuera código asíncrono e invirtiendo recursos para cambiar de contexto).

¿Qué diferencia hay entre `Task.immediateDetached` y `Task.detached`?

Task.immediateDetached (igual que su contraparte Task.detached) no hereda el contexto del actor, los valores locales de Task o la cancelación.

El aspecto "immediate" solo cambia cuándo empieza a ejecutar la tarea.

¿Por qué `addImmediateTask` dentro de un `TaskGroup` puede hacer que el trabajo se vuelva serial en lugar de paralelo?

La idea de usar un TaskGroup es para que las tareas se ejecuten de forma paralela. Si ellas hacen bastante trabajo síncrono, entonces prácticamente puede convertirse en una ejecución serial de las mismas.

El hecho de que una tarea immediate bloquee al executor antes de que se añada la siguiente tarea al grupo aparenta como si solo se ejecutara una tarea a la vez.

Comprensión propia

Sin mirar el texto, ¿puedes explicar con tus palabras qué ocurre paso a paso cuando se llama a `Task.immediate` desde una función sincrónica en el `MainActor`?

¿Cuáles son los tres casos que el autor menciona como válidos para usar tareas inmediatas?

Repaso crítico

¿Qué criterio usarías para decidir entre `Task`, `Task.immediate` y `Task.detached` en un caso real de tu propio código?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Usar un ejecutor de actor personalizado

GoyesDev — Sat, 25 Apr 2026 16:36:02 +0000

Preguntas

¿En qué situaciones el executor por defecto de Swift resulta insuficiente y cuándo debería considerarse un ejecutor personalizado?

No se quiere usar el pool de hilos global cooperativo.
Se quiere usar una cola serial específica.
Se quiere enganchar un hilo específico.

Puede ser el caso de una biblioteca de terceros que espera recibir un DispatchQueue serial para orquestar sus operaciones.

¿Qué diferencia hay entre un `SerialExecutor` y un `TaskExecutor`, y para qué sirve cada uno?

Un SerialExecutor sirve para despachar tareas en un actor, mientras que un TaskExecutor sirve para despachar tareas en un Task.

¿Por qué es importante que el actor mantenga una referencia fuerte al ejecutor cuando se usa `asUnownedSerialExecutor()`?

asUnownedSerialExecutor() entrega una referencia simple a un objeto en el heap sin conteo de referencias. Por esta razón, si no se retiene la referencia, el objeto se pierde.

¿Cómo funciona el método `enqueue(_:)` dentro de un `SerialExecutor` basado en `DispatchQueue`?

Se despacha una tarea en la cola seria (i.e. dispatchQueue.async) que consiste en ejecutar síncronamente un UnownedJob en un SerialExecutor (i.e. unownedJob.runSynchronously(on: unownedExecutor)).

final class DispatchQueueExecutor: SerialExecutor {
  private let dispatchQueue: DispatchQueue
  init(dispatchQueue: DispatchQueue) {
    self.dispatchQueue = dispatchQueue
  }

  func enqueue(_ job: consuming ExecutorJob) {
    let unownedJob = UnownedJob(job)
    let unownedExecutor = asUnownedSerialExecutor()

    dispatchQueue.async {
      unownedJob.runSynchronously(on: unownedExecutor)
    }
  }
}

actor LoggingActor {
  private let executor: DispatchQueueExecutor
  nonisolated var unownedExecutor: UnownedSerialExecutor {
    executor.asUnownedSerialExecutor()
  }

  init(dispatchQueue: DispatchQueue) {
    self.executor = DispatchQueueExecutor(dispatchQueue: dispatchQueue)
  }

  func log(_ message: String) {
    print("[\(Thread.current)]: \(message)")
  }
}

¿Qué métodos permiten configurar una preferencia de ejecutor para tareas no aisladas a un actor?

Primero hay que crear un TaskExecutor. Notar en el siguiente código cómo se conforma TaskExecutor y cómo se despacha dentro de la cola serial (i.e. dispatchQueue.async) una tarea que consiste en ejecutar síncronamente el job recibido (i.e. unownedJob.runSynchronously(on: unownedExecutor)):

final class DispatchQueueTaskExecutor: TaskExecutor {
  private let dispatchQueue: DispatchQueue
  init(dispatchQueue: DispatchQueue) {
    self.dispatchQueue = dispatchQueue
  }
  func enqueue(_ job: consuming ExecutorJob) {
    let unownedJob = UnownedJob(job)
    let unownedExecutor = asUnownedTaskExecutor()

    dispatchQueue.async {
      unownedJob.runSynchronously(on: unownedExecutor)
    }
  }
}

Luego, al definir el Task, se le pasa el ejecutor preferido:

struct DispatchQueueTaskExecutorTests {
  @Test
  func execute() async {
    let queue = DispatchQueue(label: "com.logger.queue")

    let taskExecutor = DispatchQueueTaskExecutor(dispatchQueue: queue)

    await Task(executorPreference: taskExecutor) {
      print("Task Executor example")
    }.value

    #expect(1 == 1)
  }
}

¿Qué métodos permiten configurar una preferencia de ejecutor para tareas aisladas a un actor?

Para ejecutar una tarea aislada a un actor se usa runSynchronously(isolatedTo:taskExecutor:) en lugar de runSynchronously(on:) como se muestra a continuación:

final class DispatchQueueTaskExecutor: TaskExecutor {
  private let dispatchQueue: DispatchQueue
  init(dispatchQueue: DispatchQueue) {
    self.dispatchQueue = dispatchQueue
  }
  func enqueue(_ job: consuming ExecutorJob) {
    let unownedJob = UnownedJob(job)
    let unownedExecutor = asUnownedTaskExecutor()

    dispatchQueue.async {
      unownedJob.runSynchronously(isolatedTo: DispatchQueueExecutor.loggingExecutor.asUnownedSerialExecutor(), taskExecutor: self.asUnownedTaskExecutor())
    }
  }
}

Mostrar un ejemplo donde se comparta un executor entre actores

Se debe mantener una referencia al executor como si fuera un singleton (e.g. static let loggingExecutor). Luego, el actor hará referencia a ese singleton desde var unownedExecutor: UnownedSerialExecutor.

extension DispatchQueueExecutor {
  static let loggingExecutor = DispatchQueueExecutor(
    dispatchQueue: DispatchQueue(label: "com.logger.queue", qos: .utility)
  )
}

actor SharedExecutorLoggingActor {
  nonisolated var unownedExecutor: UnownedSerialExecutor {
    DispatchQueueExecutor.loggingExecutor.asUnownedSerialExecutor()
  }

  func log(_ message: String) {
    print("[\(Thread.current)] \(message)")
  }
}

Recordar sin mirar

¿Cuál es la diferencia entre compartir un ejecutor entre múltiples actores y que cada actor tenga el suyo propio? ¿Qué implicaciones tiene esto en la concurrencia?

¿Qué restricción importante existe al combinar TaskExecutor y SerialExecutor en un mismo tipo?

Revisión y reflexión

El artículo describe los ejecutores personalizados como una "solución excepcional". ¿En qué escenarios concretos del desarrollo real estaría justificado usarlos frente al executor por defecto?

¿Qué riesgos o errores podrían surgir si se implementa incorrectamente un ejecutor personalizado, por ejemplo usando una cola concurrente donde se requiere una serial?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Herencia de aislamiento de actores mediante el macro #isolation

GoyesDev — Sat, 25 Apr 2026 13:26:31 +0000

Preguntas

¿Qué problema concreto resuelve el macro `#isolation` en la concurrencia de Swift?

#isolation es una ayuda sintáctica (como #file o #line) que produce una referencia al actor que aisla el código en cuestión o nil si el código es nonisolated.

Se usa en conjunto con el modificador de parámetro isolated que permite ejecutar el código de un método aislado en el actor marcado con isolated.

#isolation ayuda a crear código genérico que recibe un parámetro isolated y se le pasa por defecto una referencia al actor que invocó dicho código.

¿Por qué las funciones asíncronas normalmente "rompen" el aislamiento del actor llamador?

Generalmente las funciones asíncronas son non-isolated, provocando posibles puntos de suspensión innecesarios y limitando la capacidad del código de trabajar con datos no-Sendable dentro del contexto de un actor.

¿En qué situaciones sería útil heredar el aislamiento del actor en lugar de usar `@MainActor` directamente?

Usar directamente @MainActor implica asumir que el código invocador también se ejecuta en MainActor. Lo ideal es no asumir esto y, en su lugar, mejor heredar el contexto de aislamiento del invocador.

Según el artículo, ¿cómo funciona el macro `#isolation` como argumento por defecto en un parámetro `isolated`?

#isolation devuelve una referencia al actor invocador o nil si se invocó desde nonisolated

¿Por qué el compilador se queja cuando `sequentialMap` llama al closure `transform` sin usar `#isolation`?

El closure transform, en Swift 6.0, es de tipo nonisolated(nonsending) y el método sequentialMap originalmente es nonisolated.

Invocar sequentialMap desde @MainActor implica usar un await porque se va a salir del dominio MainActor.

El closure que se pasa a transform está aislado en MainActor y usa valores de ese dominio (porque la colección names se definió en MainActor y, por ende, los valores de tipo Element están en ese actor - Aunque particularmente en este ejemplo, String es Sendable). Además, el closure captura el contexto de @MainActor, y al ser nonisolated(nonsending) no puede cruzar hacia el dominio nonisolated de sequentialMap de forma segura.

Entonces, parte de MainActor, sale a nonisolated, pero trae contexto del dominio de MainActor que no puede cruzar de forma segura (por ser nonsending). Por esta razón se explota.

extension Collection where Element: Sendable {
  nonisolated func sequentialMap<Result: Sendable>(
    transform: (Element) async -> Result
  ) async -> [Result] {
    var results: [Result] = []
    for element in self {
      results.append(await transform(element))
    }
    return results
  }
}

struct Test {
  func execute() {
    Task { @MainActor in
      let names = ["Antoine", "Maaike", "Sep", "Jip"]
      let lowercaseNames = await names.sequentialMap { name in
        await lowercaseWithSleep(input: name)
      }
      print(lowercaseNames)
    }
  }
  @MainActor 
  func lowercaseWithSleep(input: String) async -> String {
    input.lowercased()
  }
}

En la solución, en lugar de que el método sequentialMap sea nonisolated, y que transform sea nonisolated(nonsending), se hereda el dominio del actor invocador con isolated y se pasa por defecto #isolation. Esto provoca que el closure tranform se ejecute en el dominio de aislamiento de isolated y resuelve el error.

extension Collection where Element: Sendable {
 func sequentialMap<Result: Sendable>(
    isolation: isolated (any Actor)? = #isolation,
    transform: (Element) async -> Result
  ) async -> [Result] {
    var results: [Result] = []
    for element in self {
      results.append(await transform(element))
    }
    return results
  }
}

¿Qué cambio específico en la firma de la función resuelve el problema de las data races?

isolation: isolated (any Actor)? = #isolation

¿Cuáles son los tres beneficios de rendimiento y seguridad que menciona el artículo al usar herencia de aislamiento?

Evita usar suspensiones innecesarias.
Permite pasar valores no-Sendable.
Evita detrimento en el rendimiento al cambiar de contextos.

Recite

Sin mirar el código, ¿puedes describir cómo quedaría la firma completa de `sequentialMap` usando `#isolation`?

Explica con tus propias palabras la diferencia entre una función aislada en un actor y una función `non-isolated`.

¿Por qué no era suficiente marcar `sequentialMap` directamente con `@MainActor` para resolver el problema del ejemplo?

Revisión

¿En qué tipos de proyectos o situaciones reales aplicarías el macro `#isolation`? ¿Por qué el artículo advierte que no es para todos los proyectos?

¿Cómo se relaciona la herencia de aislamiento de actores con el concepto de "cambio de contexto" (context switching) y el rendimiento de la app?

¿Qué pregunta o concepto del artículo quedó menos claro y cómo podrías investigarlo más?

Nota

Al hacer los experimentos del código en Xcode 26.4 pude notar que los errores descritos por el artículo no salían. Esto se debe a que tenía marcada la opción por defecto SWIFT_APPROACHABLE_CONCURRENCY = YES que habilita la funcionalidad NonisolatedNonsendingByDefault de Swift 6.2 que cambia cómo funcionan los closures nonisolated async:

En Swift 6.0 el closure transform es nonisolated y Sendable, lo que le permite cruzar hacia el contexto nonisolated de sequentialMap llevando valores del @MainActor — de ahí la carrera de datos y el error del compilador.
En Swift 6.2, el closure transform se vuelve implícitamente nonisolated(nonsending), lo que impide que cruce fronteras de concurrencia de forma insegura. Por eso el compilador ya no reporta el error.
El macro #isolation era la solución manual a este problema en Swift 6.0, que Swift 6.2 resuelve automáticamente con NonisolatedNonsendingByDefault.

Según el razonamiento anterior, podría pensar que marcar con nonisolated(nonsending) al closure transform bastaría para que no salga el error, sin embargo, esto no es así.

nonisolated(nonsending) le dice al compilador: "este closure no puede cruzar fronteras", pero sequentialMap sigue siendo nonisolated. Por esta razón, el compilador detecta que estoy mandando el closure a otro dominio y reporta el error. Por esta razón, es necesario poner el parámetro isolation: isolated (any Actor)? = #isolation, lo que le permite al compilador deducir el actor que aisla al método sequentialMap.

Cuando Swift 6.2 aplica nonisolated(nonsending) automáticamente con SWIFT_APPROACHABLE_CONCURRENCY = YES también ajusta cómo el compilador razona sobre el sitio de llamada:

El compilador ya sabe que el closure es nonisolated(nonsending) y, en lugar de tratarlo como un valor que se envía a sequentialMap, lo trata como un valor que permanece en el dominio del llamador (@MainActor) durante toda la ejecución. Así se cumple la restricción del closure sin necesidad de anclar la función con #isolation.

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

[SC] Reentrada de actores

GoyesDev — Fri, 24 Apr 2026 22:58:41 +0000

Preguntas

¿Qué significa exactamente la "reentrada de un actor" (actor reentrancy)?

Al usar await dentro de un actor, otra tarea potencialmente puede ser ejecutada mientras que la primera está suspendida.

actor Player {
  var name = "Anonymous"
  var score = 0

  func addToScore() {    
    Task {
      score += 1
      try? await Task.sleep(for: .seconds(1))
      print("Score is now \(score)")
    }
  }
}

let player = Player()
await player.addToScore()
await player.addToScore()
await player.addToScore()

try? await Task.sleep(for: .seconds(1.1))

En el ejemplo anterior, cada vez que el Task del actor se suspende en await Task.sleep(for: .seconds(1)) permite que actor ejecute cualquier otra tarea. A esto se le conoce como "interleaving".

"Actor reentrancy" es el fenómeno que se produce cuando, debido al interleaving, una tarea modifica de forma inesperada el estado que estaba usando otra tarea.

El problema se resume en que el estado del actor puede cambiar entre dos líneas si hay un await de por medio.

¿Por qué salir temporalmente de un actor puede causar comportamiento inesperado?

Cuando se sale del actor y se vuelve a entrar, es posible el estado ya haya cambiado. Por esta razón, antes de salir del dominio del actor, hay que procurar terminar las operaciones que cambian el estado.

¿Qué condición permite que otras tareas "entren" al actor mientras este está suspendido?

Un punto de suspensión.

¿Cómo afecta el uso de `await` al flujo de ejecución dentro de un actor?

El método se suspende, y el actor permite que otra tarea se ejecute mientras tanto.

En el ejemplo del `BankAccount`, ¿por qué el saldo impreso es 250.0 tres veces en lugar de 150.0, 200.0 y 250.0?

Las tres invocaciones al depósito salían a hacer un sleep. Las tres tareas modificaron el estado del BankAccount, pero después de salir del actor, volvían a depender de ese estado, por lo que las tres tareas reflejaron el estado final después de la última ejecución.

¿Qué papel cumple el `BankAccountActivityLogger` en el bug descrito?

Hace un Task.sleep que demora la ejecución, además, es otro dominio de aislamiento diferente, lo que ilustra el cambio entre dominios. Sin embargo, el problema también se presenta incluso aunque no se salga del dominio de un actor como se mostró en Player.

actor BankAccount {
  var balance: Double
  let activityLogger = BankAccountActivityLogger()

  init(initialDeposit: Double) {
    self.balance = initialDeposit
  }

  func deposit(amount: Double) async {
    balance = balance + amount
    await activityLogger.log(BankAccountActivity(activity: "Increased balance by \(amount)"))
    print("Balance is now \(balance)")
  }
}

struct BankAccountActivity {
  let date: Date = .now
  let activity: String
}

actor BankAccountActivityLogger {
  private var activities: [BankAccountActivity] = []

  func log(_ activity: BankAccountActivity) async {
    activities.append(activity)

    /// Se agrega un sleep para simular la sincronización remota de la actividad.
    try? await Task.sleep(for: .seconds(1))
  }
}

¿Por qué el `Task.sleep` dentro del `logger` es relevante para reproducir el problema?

Provoca suficiente retraso como para que otra tarea del actor pueda provocar cambios.

Recordar

¿Cuál fue la solución propuesta para corregir el bug de reentrada en el método `deposit`?

En tus propias palabras, ¿cuál es la regla general que se debe seguir antes de salir del dominio de aislamiento de un actor?

Revisión

¿En qué tipos de situaciones reales podría aparecer un bug de actor reentrancy fuera de este ejemplo?

¿Por qué el artículo dice que este es un problema "caso por caso" sin una solución universal?

Bibliografía

Van der Lee, A. (2025). Swift Concurrency Course [Curso en línea]. avanderlee.com.

DEV Community: GoyesDev

[SC] nonisolated(nonsending) y @concurrent

Preguntas

¿Cuál es la diferencia entre el comportamiento anterior y el nuevo de las funciones nonisolated async a partir de Swift 6.2?

¿Bajo qué circunstancias una tarea (Task) puede ejecutarse en el hilo principal en lugar de en un hilo en segundo plano?

¿Para qué sirve el atributo @concurrent y cuándo se debe usar?

¿Qué problema resuelve nonisolated(nonsending) y cuándo es apropiado aplicarlo?

¿Cómo se puede verificar en qué hilo se está ejecutando una tarea durante el desarrollo?

¿cómo explica el autor que el actor de llamada puede influir en el hilo donde se ejecuta una tarea?

¿Qué cambio introduce SE-461 y cuál es la justificación filosófica que da el autor al citarlo?

Recitación

¿puedes explicar con tus palabras qué ocurre cuando una función nonisolated es llamada desde un contexto @MainActor en Swift 6.2 con el nuevo flag activado?

¿Cuándo elegirías @concurrent y cuándo nonisolated(nonsending)? ¿Puedes describir un caso de uso para cada uno?

¿Cómo habilitarías el nuevo comportamiento de NonisolatedNonsendingByDefault en un proyecto de Xcode?

Revisión

¿Cómo se relacionan los conceptos de actor isolation, @MainActor y el pool cooperativo de hilos de Swift?

¿Por qué el autor advierte que este cambio puede confundir a quienes ya conocían Swift Concurrency antes de la versión 6.2?

¿Qué implicaciones de rendimiento puede tener el nuevo comportamiento por defecto si no se usa @concurrent donde corresponde?

¿En qué se diferencia el error de compilación "Sending value of non-Sendable type" del problema que resuelve nonisolated(nonsending)?

Bibliografía

[SC] Puntos de suspensión de una Task

Preguntas

¿Qué es exactamente un punto de suspensión en una tarea de Swift?

¿Por qué no todo await garantiza una suspensión real?

¿Qué es la reentrada de actores y cuándo ocurre?

¿Qué riesgos concretos introduce un punto de suspensión dentro de un actor?

¿Cómo se puede evitar el comportamiento inesperado por reentrada?

¿Qué cambia exactamente en la versión corregida del método deposit?

Recitación / comprensión

Explica con tus propias palabras por qué el balance pasa de 100 → 200 en lugar de 100 → 110.

¿Cuál es la diferencia entre un punto de suspensión posible y uno garantizado?

¿Por qué mover el await al final del método soluciona el problema de reentrada?

Revisión y síntesis

¿Cuál es la regla práctica más importante para mutar el estado de un actor de forma segura?

¿En qué situaciones de tu propio código deberías revisar dónde caen los puntos de suspensión?

¿Qué tema cubre la siguiente lección y cómo se relaciona con lo aprendido aquí?

Bibliografía

[SC] Deshacerse de la mentalidad de hilos

Preguntas

¿Por qué Swift Concurrency quiere que dejes de controlar manualmente los hilos?

¿Qué es un dominio de aislamiento y cómo reemplaza el concepto de hilo?

¿Qué papel juegan los actores (actors) en Swift Concurrency?

¿Cómo se le dan "pistas" al sistema sobre la prioridad de una tarea?

¿Por qué una tarea de alta prioridad no garantiza ejecución inmediata?

¿Qué problema resuelve la conformancia con Sendable?

Según el artículo, ¿cuáles son los tres problemas que evita dejar que Swift gestione los hilos?

En el ejemplo de código, ¿por qué la "Task 1" aparece ejecutándose en hilos distintos al inicio y al reanudarse?

Recitación

Con tus propias palabras, ¿qué significa pensar en dominios de aislamiento en lugar de hilos?

Explica por qué Sendable se vuelve necesario precisamente porque Swift puede mover trabajo entre hilos.

Revisión

¿Qué cambio mental fundamental propone el artículo respecto a cómo escribir código concurrente en Swift?

¿Cómo conectan entre sí los conceptos de actores, prioridades y Sendable dentro del modelo de Swift Concurrency?

Bibliografía

[SC] Relación entre Hilos y Tasks

Preguntas

¿Qué es exactamente un hilo y por qué tiene un alto costo de creación y cambio de contexto?

¿Por qué Swift Concurrency no garantiza en qué hilo se ejecutará una función asíncrona?

¿Qué ocurre exactamente cuando una tarea llega a un punto de suspensión con await?

¿Cómo funciona el cooperative thread pool y por qué limita los hilos al número de núcleos de CPU?

¿Qué es el thread explosion y cómo lo evita Swift Concurrency?

¿Por qué tener menos hilos no reduce el rendimiento comparado con GCD?

¿Qué demuestra el ejemplo de código con ThreadingDemonstrator sobre la relación entre tareas e hilos?

¿Por qué la tarea 1 puede reanudarse en un hilo diferente al que inició?

¿Qué diferencia introduce el modo Swift 6 respecto a acceder a Thread.current y cómo se resuelve?

Recitación

Explica con tus propias palabras qué significa "ceder el hilo" (yielding the thread) cuando se usa await.

¿Cuáles son los tres conceptos erróneos sobre Swift Concurrency que menciona el artículo? ¿Puedes refutarlos?

¿Qué tres consecuencias negativas produce el thread explosion en GCD?

¿Cómo describirías el cooperative thread pool a alguien sin experiencia en concurrencia?

Revisión

¿En qué situaciones concretas deberías seguir pensando en si algo corre en el hilo principal o en un hilo en segundo plano?

Si Swift Concurrency ya gestiona los hilos automáticamente, ¿qué valor tiene entender cómo funcionan internamente?

¿Cómo cambiaría tu forma de escribir código asíncrono ahora que sabes que await no bloquea el hilo?

¿Qué preguntas te quedan sin responder sobre el @MainActor y cómo encaja con lo aprendido aquí?

Bibliografía

[SC] ¿Cuándo usar AsyncStream en lugar de AsyncSequence?

Preguntas

¿Cuándo debería usar AsyncSequence en lugar de AsyncStream, y viceversa?

¿Qué ventajas ofrece AsyncStream para casos de uso comunes?

¿Cuál es la diferencia entre el comportamiento anterior y el nuevo de las funciones `nonisolated async` a partir de Swift 6.2?

¿Bajo qué circunstancias una tarea (`Task`) puede ejecutarse en el hilo principal en lugar de en un hilo en segundo plano?

¿Para qué sirve el atributo `@concurrent` y cuándo se debe usar?

¿Qué problema resuelve `nonisolated(nonsending)` y cuándo es apropiado aplicarlo?

¿puedes explicar con tus palabras qué ocurre cuando una función nonisolated es llamada desde un contexto `@MainActor` en Swift 6.2 con el nuevo flag activado?

¿Cuándo elegirías `@concurrent` y cuándo `nonisolated(nonsending)`? ¿Puedes describir un caso de uso para cada uno?

¿Cómo habilitarías el nuevo comportamiento de `NonisolatedNonsendingByDefault` en un proyecto de Xcode?

¿Cómo se relacionan los conceptos de actor isolation, `@MainActor` y el pool cooperativo de hilos de Swift?

¿Qué implicaciones de rendimiento puede tener el nuevo comportamiento por defecto si no se usa `@concurrent` donde corresponde?

¿En qué se diferencia el error de compilación "Sending value of non-Sendable type" del problema que resuelve `nonisolated(nonsending)`?

¿Por qué no todo `await` garantiza una suspensión real?

¿Qué cambia exactamente en la versión corregida del método `deposit`?

¿Por qué mover el `await` al final del método soluciona el problema de reentrada?

¿Qué papel juegan los actores (`actors`) en Swift Concurrency?

¿Qué problema resuelve la conformancia con `Sendable`?

En el ejemplo de código, ¿por qué la "`Task` 1" aparece ejecutándose en hilos distintos al inicio y al reanudarse?

¿Qué ocurre exactamente cuando una tarea llega a un punto de suspensión con `await`?

¿Cómo funciona el `cooperative thread pool` y por qué limita los hilos al número de núcleos de CPU?

¿Qué es el `thread explosion` y cómo lo evita Swift Concurrency?

¿Qué demuestra el ejemplo de código con `ThreadingDemonstrator` sobre la relación entre tareas e hilos?

¿Qué diferencia introduce el modo Swift 6 respecto a acceder a `Thread.current` y cómo se resuelve?

¿Cómo cambiaría tu forma de escribir código asíncrono ahora que sabes que `await` no bloquea el hilo?

¿Qué preguntas te quedan sin responder sobre el `@MainActor` y cómo encaja con lo aprendido aquí?

¿Cuándo debería usar `AsyncSequence` en lugar de `AsyncStream`, y viceversa?

¿Qué ventajas ofrece `AsyncStream` para casos de uso comunes?

¿Cómo se relacionan `AsyncSequence` y `AsyncStream` entre sí?

¿Qué ejemplo concreto usa el artículo para ilustrar el puente de delegates con `AsyncThrowingStream`?

¿Cómo funciona el método `AsyncStream.init(unfolding:oncancel:)` en el ejemplo del servicio de `ping`?

¿Por qué el artículo compara `AsyncSequence` con el protocolo `Sequence` en Swift?

Sin releer, ¿puedes explicar con tus palabras cuándo elegirías `AsyncStream` sobre `AsyncSequence`?

¿Qué hace la `continuation` en el ejemplo de `LocationMonitor` y por qué es clave?

¿Qué APIs estándar de Apple mencionadas en el artículo conforman `AsyncSequence`?

¿Qué limitación menciona el artículo sobre el ejemplo de `LocationMonitor`?

¿En qué escenarios reales, mencionados explícitamente, tiene más sentido usar `AsyncStream`?

¿Qué es un `AsyncStream` y en qué se diferencia de un `AsyncThrowingStream`?

¿Por qué podría querer reemplazar un closure de progreso/completación con un `AsyncThrowingStream`?

¿Qué sucede si no se llama a `continuation.finish()` al terminar un `stream`?

¿Qué son las `buffer policies` y cuándo tendría sentido usar cada una?

¿En qué se diferencia un `AsyncStream` de un `publisher` de `Combine`?

¿Cómo se usa el `continuation` para enviar valores, manejar errores y terminar el `stream`?

¿Qué hace el `callback onTermination` y para qué casos de uso es útil?

¿Por qué no es seguro tener múltiples consumidores de un mismo `AsyncStream`?

Explica con tus propias palabras el ciclo de vida de un `AsyncThrowingStream`, desde su creación hasta su terminación.

Sin mirar el código, describe cómo transformarías el `FileDownloader` basado en closures a uno basado en `AsyncThrowingStream`.

¿En qué escenarios concretos de tu propio código usarías un `AsyncStream` en lugar de `Combine` o callbacks?

¿Cuál es la limitación más importante de `AsyncStream` mencionada en el artículo y cómo se puede mitigar?

¿Qué es un `AsyncSequence` y en qué se diferencia de un `Sequence` normal?

¿Qué rol cumplen `AsyncIterator` y el método `next()` dentro de una secuencia asíncrona?

¿Cómo se indica el fin de la iteración en un `AsyncSequence` personalizado?

¿Por qué se recomienda usar `AsyncStream` en lugar de implementar `AsyncSequence` directamente?

¿Qué operadores de `Sequence` están disponibles también para secuencias asíncronas?

Identifica cómo el protocolo `AsyncSequence` define el acceso a valores sin generarlos por sí mismo.

Analiza cómo la cancelación con `Task.isCancelled` interactúa con el ciclo de vida de la secuencia.

Explica con tus palabras qué hace el método `next()` en el ejemplo `Counter`.

¿Cómo se usa `for await` para iterar sobre un `AsyncSequence` y por qué es necesario el `await`?

¿Qué ocurre si una secuencia asíncrona nunca termina y usas un método como `contains`?

¿En qué situaciones reales tiene sentido usar un `AsyncSequence` en lugar de un `array` estático?

¿Por qué el artículo dice que un `AsyncSequence` "prepara para valores asíncronos" aunque no siempre los envíe de forma asíncrona?

¿Qué relación existe entre los task groups vistos en lecciones anteriores y el concepto de `AsyncSequence`?

Después de leer este módulo, ¿qué preguntas tienes sobre `AsyncStream`, el siguiente tema?

¿Qué es un `Mutex` y en qué se diferencia de un `Lock`?

¿Por qué Apple introdujo un `Mutex` si ya existen los actores en Swift Concurrency?

¿Desde qué versiones de iOS y macOS está disponible el framework `Synchronization`?

¿Cómo se usa el método `withLock` y qué tipo de acceso proporciona al valor protegido?

¿Cómo permite el `Mutex` trabajar con tipos no-`Sendable` como `NSBezierPath`?

¿Qué sucede cuando múltiples hilos intentan adquirir un `Mutex` al mismo tiempo?

¿En qué situaciones concretas es preferible usar un `Mutex` en lugar de un actor?

¿Cómo se puede lanzar un error desde dentro del closure `withLock`?

¿Cuál es la conclusión principal del artículo respecto a la elección entre actores y `Mutex`?