/* Page prose (fr) */
"BlockingWithSync" = "# `sync`: bloque jusqu'à ce que ce soit terminé\n\nLe contraire de `async` est **`sync`**. Il soumet la closure puis **bloque le thread appelant** jusqu'à ce que cette closure ait terminé. Le contrôle ne te revient pas tant que le travail n'est pas fait.";
"BlockingWithSync-2" = "**Observe l'exécution:** cette fois tu obtiens un propre `1️⃣ 2️⃣ 3️⃣`. L'appel à `sync` a mis le thread principal en attente jusqu'à ce que le bloc se termine, donc `3️⃣` ne pouvait pas s'imprimer avant que `2️⃣` le fasse. Remarque que tu n'as rien gagné ici: tu as déplacé du travail vers une file d'arrière-plan mais tu l'as ensuite *attendu* sur le thread principal. Le thread principal a été bloqué tout ce temps de toute façon.\n\nC'est la leçon clé: **`sync` hors du thread principal ne t'apporte que rarement quelque chose**, parce que l'intérêt de déplacer du travail hors du thread principal est de *ne pas* l'attendre. Tu veux presque toujours `async`.\n\n`sync` a des usages précis et délibérés (comme lire brièvement une valeur depuis une file en série qui protège un état partagé); y recourir pour \"exécuter du travail d'arrière-plan\" est généralement une erreur.\n\n* callout(Danger): N'appelle jamais `DispatchQueue.main.sync { }` depuis le thread principal. Le thread principal se bloquerait en attendant la file principale, qui ne peut pas exécuter le bloc tant que le thread principal n'est pas libre. Il s'attend lui-même pour toujours. C'est un **interblocage (deadlock)**, et il fige ton app complètement. Ne l'exécute pas; sache seulement qu'il existe. Les interblocages reçoivent un traitement en bonne et due forme dans le chapitre [Les dangers de la concurrence](Concurrency%20Hazards.playgroundchapter/Overview).\n\n[Précédent](@previous)  |  page 4 sur 9  |  [Suivant: Série vs. concurrent: ordre et chevauchement](@next)";
