Primero, 66 == 64 (el tamaño máximo del grupo de subprocesos GCD) + el subproceso principal + algún otro subproceso aleatorio no GCD.
En segundo lugar, GCD no es mágico. Está optimizado para mantener la CPU ocupada con código que está principalmente vinculado a la CPU. La "magia" de GCD es que crea dinámicamente más subprocesos que las CPU cuando los elementos de trabajo de forma involuntaria y breve esperan a que se completen las operaciones.
Habiendo dicho eso, el código puede confundir el programador de GCD al dormir intencionalmente o esperar por eventos en lugar de usar las fuentes de envío para esperar eventos. En estos escenarios, el bloque de trabajo está implementando efectivamente su propio programador y, por lo tanto, GCD debe asumir que el hilo ha sido cooptado del conjunto de subprocesos.
En resumen, el grupo de subprocesos funcionará de manera óptima si su código prefiere dispatch_after() sobre "sleep()" como API y despacha fuentes sobre bucles de eventos hechos a mano (Unix select()/poll(), Cocoa runloops o Variables de condición POSIX).
"ha sido cooptado del grupo de subprocesos" ¿Qué quiere decir con la cooptación? ¿Quiere decir que el sueño u otro tipo de interrupción se interpretará como un 100% de actividad, por así decirlo, y por lo tanto, el hilo no estará disponible para su uso con despachos adicionales? –
Claro que sería bueno si pudiera proporcionar una referencia para este reclamo sobre el tamaño del grupo de subprocesos: no puedo encontrar uno en ninguna parte. –