Slashdot Mirror
New Firefox Project Could Mean Multi-Processor Support
suraj.sun writes with this excerpt from Mozilla Links "Mozilla has started a new project to make Firefox split in several processes at a time: one running the main user interface (chrome), and another or several others running the web content in each tab. Like Chrome or Internet Explorer 8 which have implemented this behavior to some degree, the main benefit would be the increase of stability: a single tab crash would not take down the whole session with it, as well as performance improvements in multiprocessor systems that are progressively becoming the norm. The project, which lacks a catchy name like other Mozilla projects (like TaskFox, Ubiquity, or Chocolate Factory) is coordinated by long time Mozillian, Benjamin Smedberg; and also integrated by Joe Drew, Jason Duell, Ben Turner, and Boris Zbarsky in the core team. According to the loose roadmap published, a simple implementation that works with a single tab (not sessions support, no secure connections, either on Linux or Windows, probably not even based on Firefox) should be reached around mid-July."
Why isn't everyone doing this?
As chipmakers demo 64 or 128 core chips, why aren't we coding and being trained in Erlang? Why aren't schools teaching this as a mandatory class? Why aren't old applications being broken down and analyzed to multithread components that don't interact? Why isn't the compiler theory concentrating on how to automate this (if possible)?
It's becoming obvious the number of cores is going to far outweigh the number of applications we'll be running five years from now (so you can't leave it up to the OS) so why isn't this a bigger concentration now in application development?
I understand a lot of server side stuff can take advantage of this (in the nature of serving many clients at once) but it's only a matter of time before it's typical on the desktop.
My work here is dung.
I think the main benefit of such a system would be responsiveness. It is very unpleasant when one tab temporarily causes the entire browser window to become completely unresponsive--including the STOP button or the button to CLOSE the misbehaving tab. The UI should never freeze for any reason.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Otherwise, I'd probably switch to google chrome eventually, which doesn't have the add-on support I enjoy from firefox.
This is great. I'm sick of that stupid integrated PDF viewer made by Adobe that always crashes my whole browser. Now it'll just crash a tiny bit.
I have left slashdot and am now on Soylent News. FUCK YOU DICE.
Does the process separation prevent badly-behaved plugins needed for a good portion of websites in existence these days *cough*flash*cough*acrobat*cough* from killing your browser when they inevitably decide to break? Both plugins have been killing me on both win32 and linux. Noscript and mozplugger or foxit help to some degree, but firefox is by far the most unstable program I use these days because of plugins.
Processes vs Threads...
I'm pretty certain that the usual 40-60 pages I have open are going to blow the memory if each runs in its own process.
GPLv2: I want my rights, I want my phone call! DRM: What use is a phone call, if you are unable to speak?
I guess it can be useful in determining which site I visit tends to create the memory leaks I still experience (even with ff3).
(as I type, this current browser session has ballooned to over 600MB...which is still better than my typical with ff2...which was 700-800MB)
maybe they can dedicate a process just for "garbage collection".
How about FireFork?
... is to surrender in order to accept buggy as hell plug-ins or memory leaks as "acceptable".
Current multithreaded Firefox is able to use multiple CPUs, being the reason of splitting the tabs into independent processes is to surrender to mediocrity. How about increasing Q&A, do proper synchronization between components, and don't allow untested components to be used without showing a big warning at installation?
Will Chrome mature to have a nice system of plugins to match the advantages of Firefox before Firefox rearchitects this very low level code?
I sometimes wonder about the FF devs - I've been wondering about the lack of a multi-threaded (at least) UI for a few years now. That project kept getting put off and put off until there was too much code to change easily. Only now that a real competitor comes along do they bother with the obvious thing that should've been put in from the start. Do FF devs not actually USE FF? Or do they not browse sites with Flash apps that go out of control and make the browser completely unresponsive? I find that hard to believe.
Whatever. At least it'll finally happen. One wonders how many people will have switched over to Chrome by the time they get this out the door, though.
They both have geek-cred, but Chrome people say Firefox is unstable, while Firefox people complain Chrome has no extensions. So it's a race between the two browsers: will Firefox get tab isolation before Chrome, or will Chrome get extension support before Firefox? Either way, we users win.
The advantage of single-processor apps in a less-than-perfect OS, is that when the app decides to chomp up all the CPU that it can grab, it doesn't cripple your machine. Moving from one to two cores for me has meant that browsers can't suck down 100% of my CPU and prevent me from even closing them for minutes at a time. This had better not let Firefox use up 100% of my machine again.
Because it's hard?
Moderators: Before moderating a comment Insightful/Informative, check to see if a child post has already refuted it.
For the last few years Google's strategy has been to make the browser the platform of choice. That would make the whole Windows, Linux, Mac, mobile whatever choice irrelevant.
Making Firefox act more like a real operating system, each "application" runs in its own process is another step in that direction. It means that my gmail browser window won't crash if I surf to some buggy website. And it means that I can run a lot of browser based application faster and more stably.
This is the next logical step for people to start using Google word processor running in firefox instead of Word or OpenOffice. Once there's a stable browser based platform for browser applications to run in, a whole world of possibilities begins to opens up.
In my experience, the HTML rendering is not the major crash or performance bottleneck issue with Mozilla.
Users want separate processes for all plugins, i.e. a switchable mode in-process or out-of-process mode selectable for each plugin through Mozilla configuration. Let the plugins crash in their own, see ndiswrapper for some ideas on that.
Users want a JavaScript engine that operates in a thread of its own (an extra thread per tab as necessary, when there is JavaScript work to do, think like dynamic thread pooling of JavaScript worker threads, most of the time 1 or 2 threads will handle JS in all your tabs).
Users want all file/disk access to be in a separate thread to the UI. I believe network I/O already is (or is non-blocking at least).
Hey move the entire file configuration/ SQLLite/ management for mozilla to a separate process that doesn't crash (even if the main Mozilla UI does). Users also want that damn stupid Linux/ext4 issue fixed and the horrible performance fixed, yes mozilla is more crazy than linux, and nope as a user it is Mozilla that crashes not the Linux the OS. In order to get application level crash recovery you make all writes to your database journaled through your own logfile. It is only the writes to that journal that need to sync to disk. Yes Eric is right mozilla should be more efficient in reducing the probability that a write to disk needs to extend a file so syncs don't cause an inode flush to stall the fs transaction throughput.
But separate web pages in separate processes, just makes no sense to me. Most of the time requires little CPU as reading/thinking time dominates the moments of Mozilla klunkyness.