/* Page prose (es) */
"CappingConcurrency" = "# Limitar cuántas se ejecutan a la vez\n\nEl patrón básico añade *todas* las tareas de entrada. Para 8 fotogramas eso está bien. Para 500, acabas de pedirle al sistema que inicie 500 hijas a la vez, cada una quizás reteniendo un fotograma decodificado en memoria, o machacando el mismo disco o servidor. Eso puede reventar la memoria, martillear el disco, o hacer que te limiten la tasa. Normalmente quieres un **límite de concurrencia**: mantener como mucho `N` fotogramas en vuelo, e iniciar el siguiente solo cuando uno termina.\n\nEn el modelo clásico tenías una perilla nativa para esto: el `maxConcurrentOperationCount` de `OperationQueue` del capítulo [Operaciones](Operations.playgroundchapter/Overview), o un `DispatchSemaphore` del capítulo [Grupos y semáforos](Groups%20and%20Semaphores.playgroundchapter/Overview). **Los grupos de tareas no tienen ese ajuste incorporado**: no hay `group.maxConcurrency = 4`. En su lugar, expresas el límite controlando *cuándo llamas a `addTask`*, y el modismo estándar es este: **ceba** el grupo con `N` tareas, y luego, dentro del bucle de recolección, añade una tarea nueva cada vez que sale un resultado. Eso mantiene el conteo en vuelo rondando `N`.";
"CappingConcurrency-2" = "**Míralo en acción:** los 20 fotogramas siguen procesándose todos, y el resultado es el mismo que en la versión de repartirlos todos. Pero en ningún instante hay más de 4 ejecutándose. Con 20 fotogramas en lotes de 4 a medio segundo cada uno, todo el asunto tarda alrededor de **2.5 segundos**, más lento que lanzar los 20 a la vez, pero con una huella acotada y predecible. Ese intercambio, un poco de tiempo de reloj a cambio de un tope duro en memoria y carga, es exactamente por qué recurrirías a él. Ajusta `maxInFlight` al recurso que estás protegiendo.\n\n* callout(Pruébalo): Pon `maxInFlight` a `1`; has convertido el grupo de nuevo en la versión secuencial, de una en una.\n\n[Anterior](@previous)  |  página 8 de 9  |  [Siguiente: Resumen](@next)";
