/* Page prose (es) */
"BlockingWithSync" = "# `sync`: bloquea hasta que termine\n\nLo opuesto de `async` es **`sync`**. Envía la clausura y luego **bloquea el hilo que la llama** hasta que esa clausura haya terminado. El control no vuelve a ti hasta que el trabajo está hecho.";
"BlockingWithSync-2" = "**Míralo en acción:** esta vez obtienes un limpio `1️⃣ 2️⃣ 3️⃣`. La llamada a `sync` dejó aparcado el hilo principal hasta que el bloque terminó, así que `3️⃣` no pudo imprimirse hasta que lo hizo `2️⃣`. Fíjate en que aquí no ganaste nada: moviste trabajo a una cola en segundo plano pero luego lo *esperaste* en el hilo principal. El hilo principal estuvo bloqueado todo el tiempo de todos modos.\n\nEsa es la lección clave: **`sync` fuera del hilo principal rara vez te aporta algo**, porque el sentido de mover trabajo fuera del hilo principal es *no* esperarlo. Casi siempre quieres `async`.\n\n`sync` tiene usos concretos y deliberados (como leer brevemente un valor de una cola serial que protege estado compartido); recurrir a él para \"ejecutar trabajo en segundo plano\" suele ser un error.\n\n* callout(Peligro): Nunca llames a `DispatchQueue.main.sync { }` desde el hilo principal. El hilo principal se bloquearía esperando a la cola principal, que no puede ejecutar el bloque hasta que el hilo principal esté libre. Se espera a sí mismo para siempre. Eso es un **interbloqueo (deadlock)**, y congela tu app por completo. No lo ejecutes; solo debes saber que existe. Los interbloqueos reciben un tratamiento como es debido en el capítulo [Riesgos de la concurrencia](Concurrency%20Hazards.playgroundchapter/Overview).\n\n[Anterior](@previous)  |  página 4 de 9  |  [Siguiente: Serial vs. concurrente: orden y solapamiento](@next)";
