/* Page prose (es) */
"TasksAreNotThreads" = "# Las tareas no son hilos\n\nHay una creencia que casi todo desarrollador trae consigo, y vale la pena desaprenderla ahora, porque todo lo de arriba depende de ello: **crear una tarea no crea un hilo.**\n\nUn **hilo** es un recurso costoso que posee el sistema operativo; es lo que de verdad ejecuta instrucciones, y tu máquina solo tiene un puñado de núcleos donde ejecutarlas. Una **tarea** es solo una unidad de trabajo que *tú* describiste. Las dos no tienen para nada el mismo tamaño: puedes crear miles de tareas, pero solo habrá un número pequeño de hilos.\n\nAsí que Swift mantiene un pequeño **grupo cooperativo de hilos** (aproximadamente **un hilo por núcleo de CPU**) y *multiplexa* tus tareas sobre él. Muchas tareas se turnan en unos pocos hilos. No eliges qué hilo; el sistema programa el trabajo por ti, usando la **prioridad** de cada tarea como pista de qué ejecutar primero (más sobre la prioridad en el capítulo [Tareas y cancelación](Tasks%20and%20Cancellation.playgroundchapter/Overview)).\n\nEsta es exactamente la razón por la que la suspensión importa. Cuando una tarea llega a un `await` y se suspende, **devuelve su hilo al grupo**, y alguna otra tarea agarra ese hilo y avanza. Cuando el resultado de tu tarea está listo, se reanuda en *cualquier* hilo del grupo que esté libre a continuación, que puede ser un hilo **distinto** del que empezó. (Por eso \"reanudarse en algún hilo más tarde,\" arriba, dice *algún*.)\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\nLa conclusión: no imagines un hilo nuevo brotando detrás de cada `Task { }`. Imagina unos pocos hilos ocupados pasándose muchas tareas entre ellos, cada tarea soltando su hilo cada vez que hace `await`.\n\n> **El modelo clásico tenía otro temperamento.** GCD también corre sobre un grupo de hilos, pero si *bloqueas* sus hilos (una espera `sync`, un semáforo, un `Thread.sleep`) GCD tiende a crear **más** hilos para compensar, un problema llamado **explosión de hilos** que puede inflarse hasta docenas de hilos peleando por los mismos núcleos. El grupo moderno se niega a propósito: se mantiene limitado a alrededor del número de núcleos y confía en que las tareas *se suspendan* (`await`) en lugar de *bloquear*. Esa única diferencia (suspender, no bloquear) es una gran parte de *por qué* existe el modelo moderno, y de por qué llamar a una API bloqueante como `Thread.sleep` dentro de una tarea es un error (el capítulo [Tareas y cancelación](Tasks%20and%20Cancellation.playgroundchapter/Overview) muestra una reteniendo un hilo como rehén).\n\n[Anterior](@previous)  |  página 4 de 8  |  [Siguiente: Await dentro de un contexto asíncrono](@next)";
