Electrolysis: News et rumeurs sur Firefox multiprocessus

[teoli2003]

Pour ceux intéressé par les développement pour un Firefox multiprocessus, j'ouvre ce fil.

Voici un bon article de ArsTechnica décrivant l'état actuel du dev:http://arstechnica.com/business/smb-res ... owsing.ars

Bientôt des nocturnes "Electrolysis". Par contre, ils sont à la recherche de développeur Mac....

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 JYP Firefox/3.5

[pirlouy]

Il me semble me rappeler que quand Google Chrome est sorti, Mozilla avait affirmé ne pas être intéressé par cette technologie. J'ai rêvé ?

Je sens qu'on va à nouveau voir des sujets de surconsommation de RAM !

[Fabrice.Tres.Net]

Il me semble me rappeler que quand Google Chrome est sorti, Mozilla avait affirmé ne pas être intéressé par cette technologie. J'ai rêvé ?

Je sens qu'on va à nouveau voir des sujets de surconsommation de RAM !

Pourquoi avec du code partagé, il n'y a que très peu de différence entre une application en mutiprocessus et un seul gros processus... du moins sous des vrais OS comme Linux/Unix...
Pour windows, je ne ferais pas le pari!

[Uther]

Et bien l'intérêt du multi-processus est justement que le code et l'espace mémoire n'est pas partagé, contrairement au multi-threading.

Message envoyé avec : Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.11

[teoli2003]

Il me semble me rappeler que quand Google Chrome est sorti, Mozilla avait affirmé ne pas être intéressé par cette technologie. J'ai rêvé ?

Oui et non. Ils ont toujours rêvé de faire fonctionner les plug-ins genre flash hors du processus principal.

D'ailleurs, il n'est pas encore décidé du modèle qui sera choisi. Un processus par fenêtre, par onglet, pour les plug-ins, etc.

Pour l'instant il s'agit de permettre à plusieurs processus d'écrire dans la même fenêtre.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 JYP Firefox/3.5

[Fabrice.Tres.Net]

Et bien l'intérêt du multi-processus est justement que le code et l'espace mémoire n'est pas partagé, contrairement au multi-threading.

Je ne comprends pas ton point.
Si on considère que c'est n fois le même processus qui est exécuté en parallèle, il est possible de partager le même code, qui est chargé une seule fois en mémoire, c'est comme cela sur Unix depuis les années 1990.
Un processus est constitué d'au moins des segments code + pile + données. Les OS à mémoire virtuelle gèrent chaque segment indépendamment.
Dans le cas d'un navigateur à un processus par onglet, on peut imaginer que le code exécuté sera identique quelque soit l'onglet, et comme ce code ne va pas changer, il est donc possible de le partager; les librairies partagées ont hérité de ces principes.
Bien entendu, les segments piles et données seront les spécifiques puisqu'ils contiendront la description de la page et l'état de chaque onglet.
Pour communiquer avec le manager, il y aura un segment de mémoire partagé.

A un instant donné, il est logique de penser qu'un système mutiprocessus consommera un peu + de mémoire qu'un système mono-processus car certaines données (comme les variables d'environnement) seront dupliquées dans les différents procesus. Mais en dynamique, ce ne sera pas le cas, car à la fermeture d'un onglet la mémoire sera libérée (les leaks disparaitront), et les nouveaux onglets utiliseront une mémoire vierge sans le gruyère dans la partie dynamique de la mémoire.

[pirlouy]

D'après la BD de Google à propos de Chrome, il montrait qu'à la fermeture d'un onglet, tout l'espace était utilisable; ça ne mentionnait pas des parties partagées. :/

Mais bon, c'est peut-être possible ce que tu dis, je n'y connais pas assez pour prouver le contraire.

[Fabrice.Tres.Net]

Si l'un des buts est de limiter l'impact des trous de sécurité, ou de limiter les crashs, il faut réduire les zones mémoires en commun.
D'ailleurs je ne vois pas l'intérêt de pouvoir écrire dans les données des autres onglets, si ce n'est pour propager étendre l'action des failles ou des bugs éventuels.
S'il y a des données à échanger entre 2 onglets, autant le faire via IPC ou via le manager général.