Voici quelques nouvelles du projet Electrolysis de Mozilla Firefox.
Pour ceux qui se le rappelle, Electrolysis est le projet de rendre Firefox plus multi-tâche, avec, entre autre, une séparation des processus par onglets (et bien d'autres).
Ce projet avait été abandonné une première fois, pour finalement être repris.
Le travail continue, et la fin du mois du juillet a vu une séance de test des modules complémentaires pour faire avancer les développeurs sur ce sujet. À l'issue de cette journée, 15 rapports de bogues furent ouverts, et une vingtaines de modules ont été notés comme fonctionnant parfaitement.
L'effort sera priorisé en fonction du nombre d'utilisateurs des modules d'après cette page.
La version M1 d'e10s (le nom raccourci d'Electrolysis), dont le but est de pouvoir être utilisée par un utilisateur λ dans les nocturnes, mais en étant désactivé par défaut, n'est plus qu'à 1 bogue de se faire.
Un carnet de route a été établi permettant d'établir un peu le travail restant.
Désormais, e10s permet une expérience proche de la normale, en utilisant des processus séparés par onglets, et en utilisant 1 processus de rendu par onglet. Néanmoins, il est, par exemple, impossible d'imprimer, ou de lire un fichier PDF avec le lecteur intégré.
Le projet est donc bien vivant et avance sûrement.
Le mot de la fin : certains voudraient qu'Electrolysis soit prêt (dans Aurora par défaut ? ou en stable ? À vous de spéculer !) pour fêter l'anniversaire de la première décennie de la version 1.0 de Mozilla Firefox le 9 novembre prochain.
# Consommation mémoire
Posté par Fabimaru (site web personnel) . Évalué à 10.
Avoir un système à la Chrome ne va-t-il pas mener à un consommation mémoire à la Chrome? (c'est à dire plus importante avec un grand nombre d'onglet)
Ça m'inquiète un peu.
[^] # Re: Consommation mémoire
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Faudra voir. Au pire, il y aura peut-être une extension pour rétablir l'ancien comportement (c'est 1 preférence à desactiver, ou un attribut XUL à enlever sur chaque onglet, pas sorcier à priori).
[^] # Re: Consommation mémoire
Posté par Xinfe (site web personnel) . Évalué à 1.
Tu veux dire plus de 763Mio consommés pour 11 onglets ouverts et une poignée d'extensions ? C'est possible ça ? J'utilise Firefox pour de multiples raisons, mais la vitesse de Chromium me manque.
Et oui, le moteur JS de Firefox est plus rapide dans les tests SunSpider mais l'Autre est plus réactif à l'utilisation.
Du coup, j'attends avec impatience cette amélioration histoire d'éviter de freezer tout le navigateur quand un bout de JS récalcitrant fout le boxon dans un onglet indéterminé.
[^] # Re: Consommation mémoire
Posté par Xaapyks . Évalué à 7.
Il a parlé de mémoire allouée, aucunement de vitesse.
[^] # Re: Consommation mémoire
Posté par Xinfe (site web personnel) . Évalué à 2.
Pourtant, on a souvent un compromis entre massacrer la mémoire au profit de la vitesse ou au contraire faire faire plus de boulot au processeur pour économiser de la mémoire. Au hasard, les fonctions trigo sont souvent sous forme de LUT sur les systèmes embarqués.
Mais c'est vrai que formellement, il ne parlait que de mémoire allouée :)
[^] # Re: Consommation mémoire
Posté par Zylabon . Évalué à 4.
Il a aussi un compromis entre besoin en ressources et temps de développement :)
Please do not feed the trolls
[^] # Re: Consommation mémoire
Posté par zurvan . Évalué à 7.
chrome a trouvé un bon moyen pour limiter la consommation de la mémoire (et l'utilisation des onglets) : au delà d'une douzaine d'onglets, on n'arrive plus à lire leur titre, du coup ça dissuade de les utiliser.
Et effectivement il y a autant de processus que d'onglets chromium, par contre si je tue un processus (kill) ou si je le "termine" (dans ksysguard), ça tue tous les autres. Avec une moyenne de 65 Mo par onglet, pour 12 onglets ça me prend 500 Mo de ram. Dans Firefox avec 1400 onglets (!!) ça me prend "seulement" 2 Go (mais ils ne se rechargent que quand on clique dessus, ce qui limite la consommation)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Consommation mémoire
Posté par Marotte ⛧ . Évalué à 8.
Sous Firefox on peut configurer de telle manière que tous les onglets soient chargés au démarrage, on ne peut pas faire la configuration inverse pour Chrome ? Je connais pas du tout parce que je suis satisfait de Firefox, mais j'ai du mal à croire que Chrome n'offre pas cette possibilité.
Rassure moi c'était un test ? Ou bien tu conserves en permanence plus de 1000 onglets ouverts ?
# [référence nécessaire]
Posté par Jiehong (site web personnel) . Évalué à 6.
Lien oublié :
certains
# Process VS thread
Posté par ®om (site web personnel) . Évalué à 2.
Question bête : pourquoi utiliser un process par onglet plutôt qu'un thread par onglet ?
Je suis sûr qu'il y a une bonne explication pour Electrolysis, mais je ne la connais pas. Merci de m'éclairer ;)
blog.rom1v.com
[^] # Re: Process VS thread
Posté par Anthony Jaguenaud . Évalué à 9.
Deux process sont isolés par l'OS, donc pas de mémoire commune. Pas de risque de pollution de l'un par l'autre.
Je suppose qu'il y a un process "maître" qui gère l'interface graphique et échange les informations à afficher entre les process. Ce processus maître pourrait même dans une certaines mesure modifier la priorité des process en fonction de l'état visible ou non.
[^] # Re: Process VS thread
Posté par ®om (site web personnel) . Évalué à 1. Dernière modification le 25 août 2014 à 17:42.
Certes, mais pour l'instant c'est mono-process mono-thread, non?
Pourquoi passer directement en multi-process et pas mono-process multi-thread? Ce compromis ne pourrait-il pas économiser la consommation mémoire?
blog.rom1v.com
[^] # Re: Process VS thread
Posté par Anthony Jaguenaud . Évalué à 6.
Si, encore que le code n'est pas forcément dupliqué, il peut être en lecture, exécution à la même adresse réelle, mais pas virtuelle.
Le problème de base est la gestion des failles javascript permettant d'interagir avec d'autres onglets, voir d'isoler l'exécution des plug'in flash, java, activeX… pour qu'un seg fault ne fasse disparaître qu'un onglet et pas toute l'application, avec du travail non terminé sur un onglet.
[^] # Re: Process VS thread
Posté par navaati . Évalué à 6.
À noter que les plugins sont déjà dans des process séparés (par définition) et que firefox est déjà résistant à leur crash.
[^] # Re: Process VS thread
Posté par pasBill pasGates . Évalué à 9.
C'est une question de securite, ainsi qu'une question de reliabilite.
En mode 'plusieurs process' :
- Si un onglet crash, tes autres onglets ne sont pas affectes
- Si il y a une faille touchant un onglet, les autres onglets ne sont pas affectes non plus (une fois qu'il y aura une sandbox)
[^] # Re: Process VS thread
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Au final, cela reviens à dire que les windows manager auraient du gérer les onglets depuis longtemps. Cela me rappelle un débat une quinzaine d'année en arrière ;-)
[^] # Re: Process VS thread
Posté par reno . Évalué à 3.
Consommation en ressource vs architecture 'saine' le débat est éternel..
J'aime beaucoup Chrome mais je l'ai abandonné sur un PC qui n'a "que" 4 Go de RAM à cause de sa consommation mémoire, se faire 'swapper' le bureau c'est très désagréable..
[^] # Re: Process VS thread
Posté par pasBill pasGates . Évalué à 5.
C'est plus complique que ca. Il faut tout un systeme de sandbox et broker aussi pour permettre au processus s'occupant du rendering de demander acces au FS pour y ecrire ou lire un fichier par exemple. C'est pas juste une histoire d'onglet et d'affichage.
[^] # Re: Process VS thread
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Oui, je me souviens aussi de l'intégration de systrace à OpenBSD qui permet de réduire les attaques avec un système assez simple.
Je ne dis pas que c'est parfait mais je pense personnellement que c'était la bonne voie, quitte à l'améliorer par la suite.
[^] # Re: Process VS thread
Posté par xcomcmdr . Évalué à 10.
s/reliabilité/fiabilité.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Process VS thread
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
Mono process, oui, mono-thread, non ! Depuis toujours Firefox utilise les threads pour diverses choses, fort heureusement, sinon l'interface serait gelée au moindre octet reçu ou envoyé. Et ces dernières années il y a eu d'énormes effort pour tout faire en asynchrone et threadé (comme toutes les manipulations de fichiers, les calculs de rendu etc..). Et coté HTML/Js, les web worker ne datent pas d'hier ;-)
[^] # Re: Process VS thread
Posté par kowalsky . Évalué à 1.
D'ailleurs xmlhttprequest ne serait pas possible sans thread !
[^] # Re: Process VS thread
Posté par Moonz . Évalué à 7.
Programmation événementielle
[^] # Re: Process VS thread
Posté par tyoup . Évalué à 1.
Et les boucles événementielles délèguent bien souvent à un thread pool histoire de ne pas se blo
[^] # Re: Process VS thread
Posté par Moonz . Évalué à 4. Dernière modification le 27 août 2014 à 00:42.
Sauf nodejs, twisted, libevent,…
Tu n’as pas besoin de threads pour ne pas te bloquer : asyncio + select/epoll/autre mécanisme similaire fourni par l’OS.
De même, si Go peut utiliser plusieurs threads il peut aussi très bien tourner avec GOMAXPROCS=1 sans pour autant bloquer bêtement toutes les goroutines sur une IO/synchronisation…
[^] # Re: Process VS thread
Posté par tyoup . Évalué à 0.
Et dire que je m'imaginais qu'environ 99% des API disponibles sur Terre étaient synchrones…
[^] # Re: Process VS thread
Posté par Moonz . Évalué à 2.
Dans le monde javascript (puisqu’on parle de XMLHttpRequest à la base) le synchrone est l’exception, l’asynchrone la règle.
[^] # Re: Process VS thread
Posté par Patrick Nicolas . Évalué à 7.
Il y a aussi la question de la résilience. Si un processus plante (accès mémoire interdit par exemple), l'OS va l'arrêter.
Dans le cas d'un navigateur ayant un seul processus et un thread par onglet, tout le navigateur plante.
Dans le cas d'un navigateur ayant un processus par onglet, seul celui en erreur plante. Si le processus qui gère la fenêtre est bien fait, il peut simplement avertir l'utilisateur.
Avoir plusieurs processus complique la gestion, ajoute un léger surcoût pour les communications entre processus (gestion du cache partagé, cookies etc) mais est la seule solution pour avoir une isolation suffisante.
C'est vraiment une bonne chose que le navigateur lui-même soit encore développé, il y a des timides développements pour wayland aussi. Bientôt Firefox aura rattrapé son retard sur Epiphany.
[^] # Re: Process VS thread
Posté par Zylabon . Évalué à 1.
Il y a toujours possibilité de traiter le segfault, ma prog système est un peu rouillée mais ça doit être faisable de trouver quel thread mange de la colle après un segfault et corriger le problème.
Please do not feed the trolls
[^] # Re: Process VS thread
Posté par vg . Évalué à 3.
Bah le truc c'est qu'après un segfault tu n'as aucune idée de l'état dans lequel se trouve ton processus et tu n'a aucun moyen de revenir proprement dans un état stable et connu, dans ce cas il vaut mieux tout stopper avant d'accumuler les dégâts collatéraux.
[^] # Re: Process VS thread
Posté par Antoine . Évalué à 5.
Y a encore beaucoup trop d'options pour ça.
# Comment l'activer ?
Posté par TilK . Évalué à 4.
Pour les utilisateurs de nightly qui se demande comment activé cette fonctionnalité, c'est simple :
- Soit dans le menu "file" vous cliquez sur "New e10s window". Cela va ouvrir une nouvelle fenêtre avec ce comportement.
- Soit dans le "about.config" vous surchargez "browser.tabs.remote.autostart" à "true". Au prochain démarrage, firefox se comportera de ce manière par défaut (avec la possibilité d'ouvrir une fenêtre classique dans le menu "file").
Par contre, cela n'a pas l'air exempt de bugs. Par exemple, je ne peux pas m'authentifier sur DLFP avec e10s.
[^] # Re: Comment l'activer ?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 4.
Tu peux déposer un bug ?
[^] # Re: Comment l'activer ?
Posté par Anonyme . Évalué à 1.
Pour ma part je n’ai jamais rien qui s’affiche, mais on peut quand même naviguer si on connaît par cœur le site :D
Et sinon j’ai aussi un message qui me dit d’activer layers.offmainthreadcomposition.enabled dans les préférences pour ouvrir un nouvel onglet avec la fonctionnalité effectivement activée.
# comment ça fonctionne ?
Posté par maboiteaspam . Évalué à 2.
Salut,
Question bête, comment fait on communiquer deux processus ensemble dans ce cas de figure ?
Deux threads je vois bien via des messages. Mais deux processus ?
Les fois où j'ai fait cela, les messages passaient par des feeds à base de stoud/stderr, et ce n'était pas hyper pratique, voir même carrément dark age….
des apis/proto spécifiques ?
[^] # Re: comment ça fonctionne ?
Posté par Moonz . Évalué à 2. Dernière modification le 29 août 2014 à 12:27.
Tu as plein de mécanismes :
Et j’en oublie certainement. Tu as aussi des API multiplateformes comme 0MQ (même si de base la plupart des mécanismes ci-dessus se retrouvent de toute façon sur tous les OS majeurs).
[^] # Re: comment ça fonctionne ?
Posté par Jiehong (site web personnel) . Évalué à 2.
Tu peux même communiques via TCP/IP entre machines distantes (Par exemple, Pulsar pour Python permet ça)
Bref, l'idée, c'est d'envoyer des messages, alors tu peux faire comment tu veux.
[^] # Re: comment ça fonctionne ?
Posté par claudex . Évalué à 3.
Tu as oublié Dbus, bientôt dans votre noyau favoris.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: comment ça fonctionne ?
Posté par tyoup . Évalué à 1.
Et aussi toutes les API non multi-platformes (même si quelque part ça utilise à une fonctionnalité du mentionnée ci-dessus ou similaire).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.