Sauf qu'un logiciel sain n'a pas besoin de plusieurs process. Un processus par session, oui ça peut être utile, pour pouvoir par exemple avoir des instances avec des paramètres différents. (par session, j'entends deux sessions d'un même profil, par exemple avec et sans navigation privée)
Mais à quoi bon séparer les fonctionnalités dans différents pid ? ça augmente énormément l'overhead du à l'IPC, alors qu'on peut simplement utiliser des méchanismes de message-passing éprouvés dans un environnement parallélisé à mémoire partégée. Comme un bon scheduler ordonnance bien les threads, pas de problème, sans compter qu'un "ordonnanceur" userspace dans le programme peut s'y rajouter (aka mettre certains threads idle en fonctions de certains critères) qui a une meilleure vision du fonctionnement interne.
En outre, les capabilities linux (et POSIX aussi il me sembnle) sont des attributs "per thread", ce qui permet de mettre en place un modèle de sécurité cohérent. Pour ce qui est des crashs, bah de toute manière, si le coeur du logiciel crash, tout crash tu n'y peux rien. Et il vaut mieux travailler à la stabilité globale, gérer mieux les exceptions, ou même écrire un analyseur statique pour javascript que passer du temps à jouer à l'autruche en tentant de minimiser les dégats.
Alors non, le multi-process n'est pas du tout en faveur de chrome.
[^] # Re: Toujours pas de multithread
Posté par Enjolras . En réponse à la dépêche Firefox 8 est disponible. Évalué à 10.
Sauf qu'un logiciel sain n'a pas besoin de plusieurs process. Un processus par session, oui ça peut être utile, pour pouvoir par exemple avoir des instances avec des paramètres différents. (par session, j'entends deux sessions d'un même profil, par exemple avec et sans navigation privée)
Mais à quoi bon séparer les fonctionnalités dans différents pid ? ça augmente énormément l'overhead du à l'IPC, alors qu'on peut simplement utiliser des méchanismes de message-passing éprouvés dans un environnement parallélisé à mémoire partégée. Comme un bon scheduler ordonnance bien les threads, pas de problème, sans compter qu'un "ordonnanceur" userspace dans le programme peut s'y rajouter (aka mettre certains threads idle en fonctions de certains critères) qui a une meilleure vision du fonctionnement interne.
En outre, les capabilities linux (et POSIX aussi il me sembnle) sont des attributs "per thread", ce qui permet de mettre en place un modèle de sécurité cohérent. Pour ce qui est des crashs, bah de toute manière, si le coeur du logiciel crash, tout crash tu n'y peux rien. Et il vaut mieux travailler à la stabilité globale, gérer mieux les exceptions, ou même écrire un analyseur statique pour javascript que passer du temps à jouer à l'autruche en tentant de minimiser les dégats.
Alors non, le multi-process n'est pas du tout en faveur de chrome.