DISCLAIMER: Nightly/Firefox I use is from LOTE repo – I do not build apps – my question regards to it … I do not know how it differs from KENZ’x version.
My question is base on my experiences with Nightly as is on Haiku Nightly 64 bit.
So As you can see in Process Controller Nightly seems as it have multiple instances running actually, as the browser probably uses separated processes (teams in Haiku’s multithreading termninology) and also for any tabs as well.
This way Haiku handles them as separate applications.
1.)
Will Nightly be adopted to use Haiku’s multithreading more natively or this quirk way stays longer ?
2.)
Could Einsteinium detect more precisely which teams shoud handle altogether , and identify browser team, and skip the tabs to offer to restart ?
There has been issues reported on einsteinium GitHub page but apparently no changes to the code since 2017. So unless there’s a fork somewhere, it seems not maintained. Don’t expect too much on that side.
Thanks @Starcrasher for your reply – regarding Einsteinium fix.
Then all of my hope I would put in fitting Nightly/Firefox to Haikus threading behaviour … once in the future.
Until then I cannot let run wild the foxy browser as it is annoying that interrupts my other activities even on an another virtual desktop. Einsteinium messages reach out … anywhere you are ;j
It’s not a quirk, the multiprocess model is a design feature. Eventually once WebPositive uses the “WebKit2” architecture internally, it’ll also use a multiprocess design similar to this.
BTW, though I don’t think this will be transparent to Einsteinium, is there a way in OS to group child processes to its parent? (Like in Windows task manager.)
Ok, I thought Haiku avoid such multiprocess way as I found apps runs in one team generally.
At least I had not kill more teams but one, and then all related threads killed. if not I used Process Monitor to eliminate it.
I assumed WebKit2 would run this way,as I understood Zardshard’s explanations about 3 different processes, but I hoped its management would be solved until then that will be merged into Webpositive – to have seen Webpositive prosess, and more separate and adequately named NetworkPocess and WebProcess.
Thanks. I see I don’t have to mark child processes(teams) just for grouping parent-children as already we can inspect team IDs.
The problem is distinguishing between launching unrelated child apps from Tracker or LaunchBox or Terminal bash and Firefox or WebKit2 browsers spawning child processes to achieve feature of single app.
They should provide proper BAppkication flags (exclusive launch?) or not create BApplication at all. It is not a property how program is launched, but what program is launched.
Regarding the multiprocess behaviour of browser tabs, for an unrelated project I had to integrate Chromium Embedded framework into a game renderer, and the threading model was in my experience terrible. CEF would respawn threads as a precaution so often that it boggles the mind. I cannot phantom the design choice to restart the web parser/renderer whenever it gets stuck as it is loading an incomplete page. The crashing/restarting causes problems for upstream clients which just want a framebuffer view, all resource references are constantly invalidated. In essence, the game engine needs to constantly ask for a valid framebuffer since the previous one can be deleted behind your back.
Thanks. I don’t know BApplication flags well, i will learn that. Multiprocess apps tends to fork() it may cause BApplication duplication.
Though I am not confident I read you correctly for my poor English skill, in my knowledge, it is not only for stability but also for security why multiprocess architecture is essential for current modern Web browsers.
Isolating content process (which parses and evaluates or executes unreliable input like malformed images, scripts or stylesheets hit known or unknows bugs) and privilaged process (accessing hardware directly or utilize powerful OS APIs) is to reduce risks when malicious code/contents succeeded to attack.
And isolating content proccesses for web site boundary is for protection safe site contents (like banking account infortdmation) from attackers malicious web sites.
As we use potentially memory unsafe code to layout and run web contents, so separate processes (implies not sharing whole memory) between them is effective to reduce attack surface from memory errors like bufeer overrun.
For the security scenario you’ve described, a better more obvious architecture is to run each tab in a unique “process”, not thread, with unique memory protected address space. Then use IPC to share a framebuffer to the viewer app. Thats not the path they took.
No, not yet. Firefox codebase itself should be 32bit compatible. Probably I made one or two 64bit specific commits on porting to fix. So porting to 32bit should be not so difficult.
As building Firefox needs RAM more than 4GB, it may require cross-compiling.
