Bref, les threads sont nécessaires, utiles, mais il ne s'agirait pas de raconter des conneries et de prétendre qu'une approche multi-processus est caduque. Le contre-exemple par excellence est Google Chrome : il allie à la fois l'usage des processus et des threads.
Exactement.
L'approche multi-processur n'est pas caduque, l'approche processus only est caduque.
Tout simplement car chaque approche a un niveau de granularité différent, donc deux applications différentes.
D'où ma rogne d'avant contre le "avoid thread, use process" qui sert d'excuse généralement quand on a honte de son code qui n'est pas thread-safe.
Chrome est un très bon exemple, Chrome utilise un process par onglet pour limiter les problèmes de stabilité. Mais par processus, il utilise un mix de multi threading ( 4-8 threads ) pour le moteur JS, le rendu, etc... et d'event loop (libevent) pour les IO.
[^] # Re: ...
Posté par Firwen (site web personnel) . En réponse à la dépêche Un projet de VM Python chez Dropbox et état des lieux des autres VM. Évalué à 8. Dernière modification le 14 avril 2014 à 13:39.
Exactement.
L'approche multi-processur n'est pas caduque, l'approche processus only est caduque.
Tout simplement car chaque approche a un niveau de granularité différent, donc deux applications différentes.
D'où ma rogne d'avant contre le "avoid thread, use process" qui sert d'excuse généralement quand on a honte de son code qui n'est pas thread-safe.
Chrome est un très bon exemple, Chrome utilise un process par onglet pour limiter les problèmes de stabilité. Mais par processus, il utilise un mix de multi threading ( 4-8 threads ) pour le moteur JS, le rendu, etc... et d'event loop (libevent) pour les IO.