Vlákno názorů k článku Firefox se zbaví starých rozšíření, půjde cestou Chromu od Martin Stransky - V clanku chybi zasadni informace o e10s (Electrolysis)...

V clanku chybi zasadni informace o e10s (Electrolysis) - na rozdil od chrome nebude mit kazda zalozka svuj vlastni proces, ale jeden oddeleny proces bude renderovat obsah pro vsechny zalozky.

Tim by se melo dosahnout vyssi rychlosti a mensi pametove narocnosti na rozdil od Chrome. Aktualni testy ukazuji, ze je mozne se dostat na hodnotu +10MB navic oproti verzi FF bez e10s.

Otter browser... Zatial vyzera velmi pouzitelne

Je to přesně naopak.

1) Jedno vlákno může jet jenom na jednom jádru. I na widlích, i na tučňákovi, i kdekoliv jinde. Jinak to udělat nejde. Multiproces se rozloží mezi jádra a zvládne toho víc.
2) Oddělený proces jde hodit do stavu Suspend, vzít jeho paměť a hodit do swapu. Běžící vlákno ne. Pokud by to mělo swapovat nepoužívanou stránku, tak potřebuje další vlákno a složitou synchronizaci, nebo musí renderovací vlákno čekat na I/O operace. U samostatnýho procesu stačí centrální loader (vlákno na IO operace) a po nahrání do paměti jenom poslat procesu zprávu, že se má vzbudit, a jede se dál.
3) V tom jednom renderovacím procesu v podstatě pojede mini operační systém s přidělováním paměti tabům, jejím uvolňováním, přepínáním tasků,... A to vše v user space. Doplicitní kód proti OS, hůř otesotvaný a horší stabilita už z principu (kernel nechráněný proti přepsání aplikací). Stačí vědět kam sáhnout a člověk je na tabulce ukazatelů na data jednotlivých tabů a díky open source zná detailně jejich strukturu a kde co hledat.
4) Proces má oddělenou paměť na úrovni OS. Tzn. nasazení hardware pro hlídání adresního rozsahu. Je složitější to probořit, než bariéru uvnitř jednoho vlákna.
5) Aby mohl jeden proces přidělovat rychle paměť tabům, musí ji mít k dispozici. Velkou, souvislou oblast. Takže při initu vydojí z OS conejvíc, aby snížil granularitu. Na pure 50kB HTML + 100kB obrázků + 10kB CSS si řekne 512MB, co kdyby tam byl odkaz jinam, nabo uživatel otevřel jinou stránku...
6) Hádám, že fragmentaci paměti apod. nebude nikdo řešit....

Takže ne, dík. Tuhle technologii si na komply nepustím.

Nechapu, ted se vyjadrujete k Chrome a nebo k Firefoxu s Electrolysis? Protoze:

Chrome:
- kazdy tab ma svuj proces. Je to pomale, zere to hromadu pameti. Kazdy proces obsahuje extra webovy obsah, vcetne vsech duplict. Pro 10 tabu mate 10 procesu.

Firefox+e10s:
- jeden proces renderuje veskere UI, bezi v nem rozsireni (v JS).
- v druhem procesu bezi veskery obsah webu, vsechny taby, kod JS pro web.

Proces ve kterem bezi web muze byt sandboxovany (je to v planu). Stejne tak je mozno mit i vice procesu, pro kazdou zalozku extra (po vzoru chrome), ale neni k tomu duvod. Web a hlavni aplikace jsou prirozene oddelene (na urovni OS - procesu).

Pokud mluvite o vlaknech - v extra vlaknu probiha jen rendering webu (projekt OMTC - https://wiki.mozilla.org/Platform/GFX/OffMainThreadCompositing) a hlavnim cilem je aby pri problemu s vykresleni stranky nezamrzlo cele UI, jak se stava v soucastnosti.

V podstate ze Mozilla snazi udelat neco podobneho jako ma Chrome (oddleny web od hlavni aplikace + sandbox), ovsem s tim rozdilem aby to bylo co nejrychlejsi a potrebovalo co nejmene pameti.

Jinak to je take duvod proc je treba predelat rozsireni - pro pristup k obsahu webu bude treba pouzit IPC most, jelikoz rozsireni pobezi v hlavnim procesu Firefoxu zatim co obsah webu bude v oddelenem procesu. Viz. https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox

Jedna se o dve nezavisle technologie.

OMTC - Off Main Thread Composition - vykresleni stranky z vrstev mimo hlavni vlakno alikace, vykresluje se v jinem vlakne. Je povolene uz v soucastnem prohlizeci (Firefox 40).

e10e - fakticky beh webu (JS skripty na webu, sestaveni stranky (reflow), sestaveni vrstev) v oddelenem procesu, vykreslena stranka je posilana je pak poslana pres IPC hlavnimu procesu ktery to vykresli v okne/tabech.