Sur le sujet, il semble qu'il y aie une convergence générale que gérer chaque page sur un process différent soit la bonne stratégie. KDE le fait pour les kioslave, Gnome le fait si je me souviens bien pour son VFS, Chrome le fait pour ses pages web et Mozilla réfléchit à le faire pour ses pages web aussi.
Les threads dans ce cas ont un gros inconvénient : si le thread crash à cause d'une extension à la con (Flash a longtemps été candidat mais n'est plus le seul), crash de toute l'appli. C'est mal.
Du coup, une bonne isolation se fait à coup de processus distincts. Faire du polling actif sur des ressources, ça va quand tu n'es pas pressé mais un navigateur est pressé d'afficher la page. Il devrait donc faire du poll en permanence, c'est un coup à bouffer tout le CPU.
En fait, il y a juste des tas de stratégies, et quand on est dans l'application, on est censé mieux connaitre les besoins qu'une gestion générique faite par le noyau (même si elle est excellement bien faite, comme dans le cas du noyau linux), et donc pouvoir avoir une gestion plus optimisée de ses ressources.
Là dessus, je suis pas vraiment d'accord avec toi. L'application connaît à peu près ses besoins en ressource mais :
- elle ne connait pas l'état du système. Notamment la charge en cours du système peut influer sur le comportement considéré comme optimal.
- sur certains sujets, elle a beaucoup moins d'expérience et de savoir-faire qu'un développeur OS. Typiquement, optimiser la charge système et la fluidité de différentes tâches quand on a N tâches à exécuter (avec N variant beaucoup dans le temps) est un problème très très subtil à résoudre. Linux a des milliers d'heures de cerveaux de développeurs kernel sur la bonne façon de faire, Mozilla ne peut certainement pas prétendre faire mieux.
La bonne stratégie consiste à passer suffisamment d'informations explicites ou implicites à l'OS pour qu'il puisse prendre les bonnes décisions. Mais pas comme tu le suggères, de tout faire dans l'application.
[^] # Re: Toujours pas de multithread ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Firefox Sept : consommation mémoire nettement améliorée. Évalué à 2.
Sur le sujet, il semble qu'il y aie une convergence générale que gérer chaque page sur un process différent soit la bonne stratégie. KDE le fait pour les kioslave, Gnome le fait si je me souviens bien pour son VFS, Chrome le fait pour ses pages web et Mozilla réfléchit à le faire pour ses pages web aussi.
Les threads dans ce cas ont un gros inconvénient : si le thread crash à cause d'une extension à la con (Flash a longtemps été candidat mais n'est plus le seul), crash de toute l'appli. C'est mal.
Du coup, une bonne isolation se fait à coup de processus distincts. Faire du polling actif sur des ressources, ça va quand tu n'es pas pressé mais un navigateur est pressé d'afficher la page. Il devrait donc faire du poll en permanence, c'est un coup à bouffer tout le CPU.
Là dessus, je suis pas vraiment d'accord avec toi. L'application connaît à peu près ses besoins en ressource mais :
- elle ne connait pas l'état du système. Notamment la charge en cours du système peut influer sur le comportement considéré comme optimal.
- sur certains sujets, elle a beaucoup moins d'expérience et de savoir-faire qu'un développeur OS. Typiquement, optimiser la charge système et la fluidité de différentes tâches quand on a N tâches à exécuter (avec N variant beaucoup dans le temps) est un problème très très subtil à résoudre. Linux a des milliers d'heures de cerveaux de développeurs kernel sur la bonne façon de faire, Mozilla ne peut certainement pas prétendre faire mieux.
La bonne stratégie consiste à passer suffisamment d'informations explicites ou implicites à l'OS pour qu'il puisse prendre les bonnes décisions. Mais pas comme tu le suggères, de tout faire dans l'application.