El sistema se ralentiza hasta el punto de que se arrastra. Puede que no se bloquee realmente, porque no veo que todos los núcleos estén absolutamente ahogados con hilos hasta el punto de que un kernel no pueda manejar un preempt, y hacer un cambio de contexto. Pero puedo ver que las cosas se ralentizan inmensamente.
Pero se necesitaría un gran número de procesos para llegar a este punto incluso en un ordenador de gama baja de 300 dólares. Los núcleos de la CPU pueden manejar una inmensa cantidad de procesos que entran y salen de ellos. Y luego está el SMT (como el Hyperthreading en las CPU de Intel y la implementación del SMT en Ryzen), que permite que la tubería de un núcleo maneje dos hilos simultáneamente. Y hoy en día es muy raro ver una CPU con menos de dos núcleos, y lo más común es verlas con cuatro núcleos. Con SMT son 8 hilos.
Por supuesto, el factor real en la eficiencia de una CPU para manejar los procesos es en realidad el planificador del núcleo del sistema operativo. Los sistemas operativos modernos utilizan planificadores de procesos preventivos, lo que significa que cada proceso tiene que abandonar el núcleo/hilo en el que se encuentra cuando se produce una NMI (interrupción no enmascarable) específica. El kernel utiliza una serie de algoritmos para determinar cuánto tiempo se asigna a cada proceso antes de la preemption. Para ser honesto, es MUY raro que un proceso utilice toda su franja de tiempo, ya que mucho de lo que hace un programa es hacer llamadas al sistema para que el sistema operativo haga algo por el programa. La única vez que un proceso utilizará su tiempo asignado y será adelantado es si está haciendo algo computacionalmente intensivo o se bloquea. Ambas cosas, para que conste, son muy similares.
¿Y qué pasa con la memoria? Ese es probablemente el cuello de botella más probable para «demasiados procesos, pero esto es difícil de predecir ya que cada programa utiliza cantidades muy diferentes de RAM. Pero si la memoria RAM del sistema se agota, el sistema operativo hará uso del swapping, lo que puede ralentizar las cosas. Y cuando el espacio de intercambio se llena, incluso entonces el núcleo de un sistema operativo suele disparar un asesino OOM (Out of Memory.) en el proceso más intensivo en memoria. Esto puede resultar en un comportamiento muy impredecible si ese proceso estaba haciendo algo en el fondo, sin embargo. Esto depende en gran medida del uso que se le dé al ordenador. Yo recomiendo al menos 8 GB de RAM, idealmente 16 GB. Si está haciendo algo REALMENTE intensivo como una estación de trabajo o un servidor, de 32 a 64 GB sería SUFICIENTE.
Hay un número máximo teórico de procesos que un KERNEL puede manejar, pero suele ser un número inmenso y generalmente requeriría anular una serie de salvaguardias y algo como una bomba de bifurcación para alcanzarlo.
Pero bueno, si alguna vez tiene curiosidad por ver lo que sucede cuando un equipo se carga con «demasiados procesos» siempre puede arriesgarse a probar una bomba de bifurcación. Búscalo en Google. No creo que se puedan hacer en Windows, pero sí en casi cualquier Unix o similar a Unix debido a cómo funcionan las shells de Unix.