/* Page prose (fr) */
"WrappingUp" = "# Récapitulatif\n\nToute la promesse de GCD, c'est que tu cesses de gérer des threads et que tu commences à remettre des closures à des **files**. Familiarise-toi avec ce que fait chaque file, et avec l'unique décision `async` contre `sync`, et le reste n'est que du détail. La plupart des pièges vivent autour de `sync`, alors lis les points à retenir ci-dessous avant d'y recourir.\n\n* **GCD gère les threads pour toi.** Tu remets des closures à des **files**; tu ne crées pas de threads toi-même.\n* Trois files: **principale** (UI, en série), **globale** (arrière-plan partagé, concurrente) et **personnalisée** (`DispatchQueue(label:)`, en série par défaut). Recours à une file personnalisée pour protéger un état ou nommer une ligne de travail; pour \"sortir ceci du principal,\" `global()` est plus simple.\n* **`async`** programme le travail et rend la main immédiatement; **`sync`** bloque le thread actuel jusqu'à ce que le travail se termine. Tu veux presque toujours `async`.\n* Les files **en série** garantissent l'ordre et l'absence de chevauchement; les files **concurrentes** exécutent les tâches en parallèle et se terminent dans n'importe quel ordre. Ne dépends jamais de cet ordre de fin.\n* Le patron central est **travailler sur une file d'arrière-plan, puis revenir vers `DispatchQueue.main.async` pour mettre à jour l'UI**: toucher l'UI hors du thread principal est un comportement indéfini.\n* La **QoS** indique à GCD à quel point le travail est urgent; choisis-la en te demandant si quelqu'un attend, et s'il regarde.\n* **Piège:** `main.sync` depuis le thread principal produit un **interblocage**. Ne le fais jamais.\n\n---\n\n## La suite\n\nLa suite, c'est **[Groupes et sémaphores](Groups%20and%20Semaphores.playgroundchapter/Overview)**: comment attendre qu'un lot entier de travail dispatché se termine, et comment limiter le nombre de tâches qui touchent une ressource à la fois.\n\n[Précédent](@previous)  |  page 9 sur 9";
