La gestion d’autant de threads est très consommatrice en ressources, non seulement la création est coûteuse, mais aussi le fait d’avoir beaucoup de processus en attente du CPU. Dans le calcul scientifique on créera plutôt un pool de threads (~ nombre de cœur de la machine, à la petite blague près) qui vont traiter une liste d’attente (que ce soit une liste en dur, aka boucle for ou une liste dynamique). Tout ce qui est serveur pour répondre aux requêtes des clients devrait pouvoir être programmer comme ça, un thread s’occupe de mettre les requêtes en file d’attente, les autres de traiter les requêtes, non ?
[^] # Re: En clair
Posté par BB . En réponse au journal Vente liée : comment se tirer soi-même une balle dans le pied. Évalué à 1.
La gestion d’autant de threads est très consommatrice en ressources, non seulement la création est coûteuse, mais aussi le fait d’avoir beaucoup de processus en attente du CPU. Dans le calcul scientifique on créera plutôt un pool de threads (~ nombre de cœur de la machine, à la petite blague près) qui vont traiter une liste d’attente (que ce soit une liste en dur, aka boucle
forou une liste dynamique). Tout ce qui est serveur pour répondre aux requêtes des clients devrait pouvoir être programmer comme ça, un thread s’occupe de mettre les requêtes en file d’attente, les autres de traiter les requêtes, non ?