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.
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.
... 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?
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.
Following the link on that page Kitsune the Japanese word for fox, particularly in folklore. "The more tails a kitsune hasâ"they may have as many as nineâ"the older, wiser, and more powerful it is"
Python coder | PyQt Applications | Writer
What a load of cr*p.
Sure, on any modern system, the overhead of having "multiple copies of the same process" is minimal.
That doesn't change the fact that:
- synchronization between threads or processes is just as difficult either way. A mutex is a mutex, a semaphore a semaphore and so on.
- communication, on the other hand is much easier with threads. And just because you're using threads doesn't somehow forbid you to use "well-defined interfaces". Other things being equal, you might want to save yourself the whole copy stuff to shared memory and back mess. Remember that extra code is an extra source of bugs.
Where process have an advantage, still, is when you're running arbitrary code in one. Plugins for instance. That has the potential to crash the whole thing in a single process, while a *correctly coded* IPC can survive it. Emphasis on correctly coded because otherwise you'll end up with a lockup instead of a crash, not exactly an improvement.
Since we're talking about plugins, I'd favor processes in this specific case.
But that's not to say that processes are inherently superior to threads. They're only so in the mind of people who grew up with Unix, decided that OS architecture reached perfection in the 70s and shut their mind about threads because that was "new" and/or something Windows better at. Pitiful.
As for Erlang, I'm still waiting for an halfway decent app written in it that's used by more than 10 people. And that doesn't include that stupid router we keep hearing about: developers who can't code 6 nines of reliability out of 10 years matured specs running on custom telco-spec hardware don't deserve the title, be it in C, C++, Java or Erlang.
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.