On peut rajouter une couche à cela : Les "green threads" ou "light tread". Ce sont des threads en mode purement utilisateur. Lors de l'écriture des threads pour linux, il y a eu un grand débat pour finir par se décider pour un thread user == un thread kernel, c'est plus simple. Le fait de mettre plus de thread user par thread kernel redevient à la mode depuis les goroutines Golang.
Un thread user prend obligatoirement des ressources sur la machine (4ko de pile par exemple + descripteur), et donc la gestion limite à quelques millions de threads utilisables. Un thread léger est... plus léger.
Par contre tous appels bloquants kernel bloquent tous les green thread tournant sur le même thread kernel. Par exemple, un read() ou un write(), le kernel met en pause le thread qui fait cette demande pendant qu'il la traite alors que d'autres sont prêt à tourner.
[^] # Re: bande passante / latence
Posté par Nicolas Boulay (site web personnel) . En réponse au lien Blocking and non-blocking threads. Évalué à 4.
On peut rajouter une couche à cela : Les "green threads" ou "light tread". Ce sont des threads en mode purement utilisateur. Lors de l'écriture des threads pour linux, il y a eu un grand débat pour finir par se décider pour un thread user == un thread kernel, c'est plus simple. Le fait de mettre plus de thread user par thread kernel redevient à la mode depuis les goroutines Golang.
Un thread user prend obligatoirement des ressources sur la machine (4ko de pile par exemple + descripteur), et donc la gestion limite à quelques millions de threads utilisables. Un thread léger est... plus léger.
Par contre tous appels bloquants kernel bloquent tous les green thread tournant sur le même thread kernel. Par exemple, un read() ou un write(), le kernel met en pause le thread qui fait cette demande pendant qu'il la traite alors que d'autres sont prêt à tourner.
"La première sécurité est la liberté"