/* Page prose (fr) */
"TasksAreNotThreads" = "# Les tâches ne sont pas des threads\n\nIl y a une croyance que presque tous les développeurs apportent avec eux, et il vaut la peine de la désapprendre maintenant, parce que tout ce qui précède en dépend: **créer une tâche ne crée pas un thread.**\n\nUn **thread** est une ressource coûteuse que possède le système d'exploitation; c'est ce qui exécute réellement les instructions, et ta machine n'a qu'une poignée de cœurs pour les exécuter. Une **tâche** n'est qu'une unité de travail que *tu* as décrite. Les deux n'ont pas du tout la même taille: tu peux créer des milliers de tâches, mais il n'y aura jamais qu'un petit nombre de threads.\n\nDonc Swift maintient un petit **pool coopératif de threads** (environ **un thread par cœur de CPU**) et *multiplexe* tes tâches dessus. Beaucoup de tâches se relaient sur quelques threads. Tu ne choisis pas quel thread; le système planifie le travail pour toi, en utilisant la **priorité** de chaque tâche comme indice de ce qu'il faut exécuter en premier (plus de détails sur la priorité dans le chapitre [Tâches et annulation](Tasks%20and%20Cancellation.playgroundchapter/Overview)).\n\nC'est exactement pour ça que la suspension compte. Quand une tâche atteint un `await` et se suspend, elle **rend son thread au pool**, et une autre tâche s'empare de ce thread et progresse. Quand le résultat de ta tâche est prêt, elle reprend sur *n'importe quel* thread du pool libre à ce moment-là, qui peut être un thread **différent** de celui sur lequel elle a commencé. (C'est pour ça que \"reprendre sur un thread quelconque plus tard,\" ci-dessus, dit *quelconque*.)\n\n```\nThe pool has ~4 threads. You made 100 tasks.\n\nTask A runs on thread 2 ──await──▶ suspends, releases thread 2\n                                       │\nTask B grabs thread 2 and runs ◀───────┘\n   ...\nTask A's result is ready ──▶ resumes on whatever thread is free (maybe thread 0)\n```\n\nÀ retenir: n'imagine pas un nouveau thread surgir derrière chaque `Task { }`. Imagine quelques threads occupés qui se passent de nombreuses tâches entre eux, chaque tâche lâchant son thread chaque fois qu'elle fait `await`.\n\n> **Le modèle classique avait un tempérament différent.** GCD s'exécute aussi sur un pool de threads, mais si tu *bloques* ses threads (une attente `sync`, un sémaphore, un `Thread.sleep`) GCD a tendance à créer **plus** de threads pour compenser, un problème appelé **explosion de threads** qui peut enfler jusqu'à des dizaines de threads se disputant les mêmes cœurs. Le pool moderne refuse délibérément de le faire: il reste plafonné aux alentours du nombre de cœurs et compte sur les tâches qui *se suspendent* (`await`) au lieu de *bloquer*. Cette unique différence (suspendre, ne pas bloquer) est une grande partie de *la raison pour laquelle* le modèle moderne existe, et de pourquoi appeler une API bloquante comme `Thread.sleep` à l'intérieur d'une tâche est une erreur (le chapitre [Tâches et annulation](Tasks%20and%20Cancellation.playgroundchapter/Overview) en montre une qui retient un thread en otage).\n\n[Précédent](@previous)  |  page 4 sur 8  |  [Suivant: Faire await dans un contexte asynchrone](@next)";
