Non pas vraiment. Il s'agit ici d'avoir une granularité assez fine pour faire un switch non pas sur les threads (ce qui est plutôt lourd), mais au sein d'un même thread.
Oui, le modèle de gestion du multitâche popularisé par NodeJS a plusieurs intérêts. Le premier c'est qu'en gros il fournit un cadre assez simple de programmation multi-thread en proposant de prendre en charge complètement un thread dédié aux appels systèmes et un autre qui s'occupe de traiter les évènements correspondant à ces appels. Comme programmeur, je sais qu'a tout moment je n'ai qu'un fil d'éxécution et donc je peux laisser tomber les mutexes, j'ai des programmes moins difficiles à déboguer que le "multi-thread" total. Le second effet, qui n'est pas négligeable, est que si j'ai besoin d'ajuster la capacité de mon application, je n'ai qu'un seule variable à considérer: le nombre de processus que je veux faire tourner sur une machine. Dans le monde "complètement multi thread" j'ai un espace beaucoup compliqué à explorer: pour mon serveur apache, est-ce qu'il faut mieux 16 processus avec chacun 2 thread, 8 processus avec chacun 4 threads, etc.? Quelle stratégie utiliser pour allouer les threads dans mon application? Avoir un modèle simple pour décrire la capacité de son application est appréciable – quitte à potentiellement sacrifier un peu en efficacité en acceptant de ne pas explorer certaines formes d'organisation.
[^] # Re: Petit joueur
Posté par Michaël (site web personnel) . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 4. Dernière modification le 08 mars 2018 à 00:20.
Oui, le modèle de gestion du multitâche popularisé par NodeJS a plusieurs intérêts. Le premier c'est qu'en gros il fournit un cadre assez simple de programmation multi-thread en proposant de prendre en charge complètement un thread dédié aux appels systèmes et un autre qui s'occupe de traiter les évènements correspondant à ces appels. Comme programmeur, je sais qu'a tout moment je n'ai qu'un fil d'éxécution et donc je peux laisser tomber les mutexes, j'ai des programmes moins difficiles à déboguer que le "multi-thread" total. Le second effet, qui n'est pas négligeable, est que si j'ai besoin d'ajuster la capacité de mon application, je n'ai qu'un seule variable à considérer: le nombre de processus que je veux faire tourner sur une machine. Dans le monde "complètement multi thread" j'ai un espace beaucoup compliqué à explorer: pour mon serveur apache, est-ce qu'il faut mieux 16 processus avec chacun 2 thread, 8 processus avec chacun 4 threads, etc.? Quelle stratégie utiliser pour allouer les threads dans mon application? Avoir un modèle simple pour décrire la capacité de son application est appréciable – quitte à potentiellement sacrifier un peu en efficacité en acceptant de ne pas explorer certaines formes d'organisation.