pas du tout (ça fait quand même 6 ans que je bosses avec/sur Mozilla). Firefox, ce n'est que quelques fichiers XUL et js au dessus de XulRunner, lui-même au dessus de Gecko. Ce n'est pas Firefox qui gère les processus ou autre, c'est Gecko. Gecko est plus qu'un moteur de rendu, c'est tout un ensemble : moteur de rendu + couche reseau + couche d'abstraction du système + gestion des processus etc... Bref, tout ce qui est systeme/technique/rendu. Tu lui adjoint ensuite un toolkit XUL, et des composants utilitaires (fichiers, système de mise à jour etc), ça te donne XULRunner. À ça tu y ajoutes des composants spécifiques à ton appli, des fichiers XUL/JS et autre, ça te fait une appli : Firefox.
Actuellement, Gecko ne permet pas de charger un fichier HTML/XUL dans un processus différent. Ce n'est pas en modifiant quelques fichiers XUL et composants de Firefox qui vont permettre de le faire
>tu dis qu'il est impossible de réécrire les millions de ligne mais que les developpeurs sont en train de faire le multi-process, ce qui est bien la preuve que c'est possible d'avoir une architecture correcte sans tout réécrire
Si l''architecture de Gecko aujourd'hui, permet de developper le multi-process sans avoir à tout réécrire, c'est parce que Gecko évolue sans cesse. L'idée du multi process dans Gecko n'est pas nouvelle, ça fait plusieurs années que les core-developpers y pensent (cf sur les newsgroup de Mozilla). Aujourd'hui, il reste encore beaucoup de boulot, et ils sont quand même une petite équipe à temps complets pour y travailler. ça va représenter des patchs énormes quand même. Quand je dis, "sans tout réécrire", il faut relativiser en ayant en tête les millions de lignes de codes Mozilla...
>c'est que quand Chrome est sortie cela a mis en lumière que l'architecture de FF était pourrie..
non, raté. ça juste mis en lumière l'idée qu'il est intéressant d'exploiter aujourd'hui le multi processing dans les browser, grâce à la généralisation des processeurs multicoeurs, mais aussi de l'usage que l'on fait aujourd'hui d'un navigateur.
[^] # Re: Consommation mémoire ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 6.
pas du tout (ça fait quand même 6 ans que je bosses avec/sur Mozilla). Firefox, ce n'est que quelques fichiers XUL et js au dessus de XulRunner, lui-même au dessus de Gecko. Ce n'est pas Firefox qui gère les processus ou autre, c'est Gecko. Gecko est plus qu'un moteur de rendu, c'est tout un ensemble : moteur de rendu + couche reseau + couche d'abstraction du système + gestion des processus etc... Bref, tout ce qui est systeme/technique/rendu. Tu lui adjoint ensuite un toolkit XUL, et des composants utilitaires (fichiers, système de mise à jour etc), ça te donne XULRunner. À ça tu y ajoutes des composants spécifiques à ton appli, des fichiers XUL/JS et autre, ça te fait une appli : Firefox.
Actuellement, Gecko ne permet pas de charger un fichier HTML/XUL dans un processus différent. Ce n'est pas en modifiant quelques fichiers XUL et composants de Firefox qui vont permettre de le faire
>tu dis qu'il est impossible de réécrire les millions de ligne mais que les developpeurs sont en train de faire le multi-process, ce qui est bien la preuve que c'est possible d'avoir une architecture correcte sans tout réécrire
Si l''architecture de Gecko aujourd'hui, permet de developper le multi-process sans avoir à tout réécrire, c'est parce que Gecko évolue sans cesse. L'idée du multi process dans Gecko n'est pas nouvelle, ça fait plusieurs années que les core-developpers y pensent (cf sur les newsgroup de Mozilla). Aujourd'hui, il reste encore beaucoup de boulot, et ils sont quand même une petite équipe à temps complets pour y travailler. ça va représenter des patchs énormes quand même. Quand je dis, "sans tout réécrire", il faut relativiser en ayant en tête les millions de lignes de codes Mozilla...
>c'est que quand Chrome est sortie cela a mis en lumière que l'architecture de FF était pourrie..
non, raté. ça juste mis en lumière l'idée qu'il est intéressant d'exploiter aujourd'hui le multi processing dans les browser, grâce à la généralisation des processeurs multicoeurs, mais aussi de l'usage que l'on fait aujourd'hui d'un navigateur.