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.
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.
On any modern system, there is very little memory overhead to having multiple copies of the same process. They will share read-only or copy-on-write versions of the executable code and resources loaded from shared libraries and the the program binary, as well as any resource files opened with mmap() or the Windows equivalent. The only real overhead is relocation symbols, which are a tiny fraction of most processes. In exchange for this small overhead, you have the huge benefit of having completely isolated instances which only communicate with each other through well-defined interfaces.
Threads are an implementation trick. They should not be exposed as a programmer abstraction unless you want people to write terrible code. Go and learn Erlang for how parallel code should be written.
I am TheRaven on Soylent News
I tried explaining this on DIGG, but to not have the title understand it on Slashdot is depressing!
I think there is an advantage to processes pre tab against a code injection attack
Also if you had Firefox-gui, Firefox-net, Firefox-Gecko, Firefox-Profile, Firefox-file you could give each one a different SElinux/apparmor/UAC profile.
Im not sure what the performance trade off would be like so i sincerely hope that there is a single binary compiler option. I also think that a good balance to prevent the security hit on per-tab processes is to only put https tabs in separate processes (additionally it would be smart to prevent extensions running on these pages (GUI extensions would still work, but nothing that touched the page).
Are processes even needed for security though? can threads be locked down to achieve this without the performance hit? (and additionally, lock down extensions?)
IranAir Flight 655 never forget!
Tools->Options->Applications. Search for 'pdf' and disable it from using the plugin to auto downloading and opening the file.
I also recommend using Foxit Reader instead of Acrobat for viewing PDFs, it too has a in browser plugin, but downloading and opening the application is quicker at least for me; the actual application usually opens in less than a second.
But back on topic, I have been using chrome more and more lately due to the fact that no tab can crash the entire browser. I still use Firefox though due to the plugins and the web developer toolbar with firebug (chrome's inspector is pretty close though). If Firefox doesn't catch up quick enough I might switch over completely when chrome has more advanced plugin support.