Slashdot Mirror
Firefox To Get Multi-Process Browsing
An anonymous reader writes with news that multi-process browsing will be coming to Firefox. The project is called Electrolysis, and the developers "have already assembled a prototype that renders a page in a separate process from the interface shell in which it is displayed." Mozilla's Benjamin Smedberg says they're currently "[sprinting] as fast as possible to get basic code working, running simple testcase plugins and content tabs in a separate process," after which they'll fix everything that breaks in the process. Further details of their plan are available on the Mozilla wiki, and a summary is up at TechFragments.
Actually, they're talking about multiple processes, not multithreading. Threads all belong to a single process, which, if it crashes, will bring down all of its threads. Running the shell in one process, then each tab/window in its own process means that, much like Chrome, a single page can't bring down the myriad of tabs/windows you might have open, if you browse the web like I do.
-Matthew Riley "TofuMatt" MacPherson
I have a website
According to the Ars coverage:
It was probably too large a project to consider doing without a pressing need. Chrome and IE8 supplied that pressure.
The Rise and Fall of Online Community
So your single-core cpu is only ever capable of running a single process? The advantages of a multi-process browser go way beyond running the processes on separate cores.
>Most of the people are still running a single core CPU.
Do not confuse multi-process with multi-processor (or multi-core).
Even a single core machine can make use of multiple tasks, or threads, or processes, to get more work done while waiting for one task to complete.
When monolithic code reaches a point where it is waiting for data from the server, it stalls. Multiprocess code has another process it can put to use rendering the images, or playing the goddamed flash.
This isn't really about CPU/Core counts, having tabs/plug-ins running in a separate process is useful because if that page/plug-in crashes that process, the remaining pages won't be effected. I highly doubt they will be dabbling with being able to set which processor a certain process runs on (just yet).
This won't really make use of extra processors/cores, that's what threads (should) already do, even if the application doesn't have any special code to do so.
Correct me if I'm wrong, but wasn't Firefox working on JS speed before Chrome was announced?
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
Threading for Javascript? Not possible! Stop asking for something that can't be done! The Firefox devs cried!
Opposition to threading by Firefox devs came from, among others, Brendan Eich, the inventor of Javascript. You can read his well supported arguments on Bugzilla.
That doesn't excuse Firefox devs from not supporting a parallel architecture earlier, from which users would significantly benefit. But the conversation on that link is an oculus into the reasoning behind not having a parallel architecture earlier.
One way to implementing multi-process Firefox is first allow XPCOM to work across process. i.e. allow objects to be via XPCOM that are actually spawned in another process, one explicitly created for the task. In COM it had a thing called a running object table (ROT). When you create a process hosted object it looks to see if one is running already, and if not it uses the registry info to spawn one. Then it waits for it to start and then it tells the process to create the object, sets up all the marshaling etc. XPCOM could do something similar, though it would have to do so in a cross-platform manner. I assume that Firefox would have to determine when creating a browser object first if it was chrome or content, and if it was content to spawn a host process and then set up the interfaces. Once set up and assuming the interfaces were efficient, the effect would be largely transparent.
The biggest performance hit would probably be on anything which tried to call or iterate over the DOM boundary between chrome and content. For example chrome which introspected content would suffer because all the calls would have to be serialized / deserialized.
Personally I think its feasible but it would hit performance. An alternative would be to just host plugins in another process. Windowless plugins might be a pain to implement but at least you could kill the other process if a plugin goes nuts which seems to happen all too frequently for me.
The machine I'm currently on is a single core machine running XP (1.6 GHz if I'm not mistaken...so lazy I don't even want to pull up the specs!). I've been using Chrome for months on this thing and it's lightning fast. Your concern over speed is unfounded.
Yes, they were. TraceMonkey was started in earnest in early summer 2008. Chrome was (accidentally) announced 1 September 2008.
The Rise and Fall of Online Community
Ask your admins to change the proxy PAC to not using the isInNet function, as this
requires the DNS to check if every domain/hostname exists before deciding what proxy
to use... isnt easy to solve...
i work around with this:
if ( shExpMatch(url, "*127.0.0*") ||
shExpMatch(url, "*192.168.*") ||
shExpMatch(url, "*10.15.*") ||
shExpMatch(url, "*10.16.*") ||
shExpMatch(url, "*10.17.*")
){ if ( isInNet(host, "127.0.0.0", "255.0.0.0") ||
isInNet(host, "192.168.0.0", "255.255.0.0") ||
isInNet(host, "10.15.0.0", "255.255.0.0") ||
isInNet(host, "10.16.0.0", "255.255.0.0") ||
isInNet(host, "10.17.0.0", "255.255.0.0")
) { return "DIRECT"; }
else { return "PROXY 192.168.1.10:3128"; }
}
this way it just use the "bad" function if there is a IP in the URL...
all rest, its defined using domains/hostnames, no need for the isInNet
good luck
Higuita
My firefox actually does freeze while rendering a page. It's mostly obvious on my slower linux box. Not that I'm disputing its multi-threaded nature, it clearly *can* do two things at once, just not the things I need it to do (like load slashdot while allowing me to click back to another tab).
A non-blocking call implies multi-threaded design, genius.
It really doesn't. Maybe a similar design to a multithreaded app, but more accurately an event model, not a thread model. It's cooperative multitasking, which means it won't hit multiple processors, and generally won't have anywhere near the same kind of concurrency issues.
I suppose you could make the argument that the OS is doing the threading for you, or that it's a kind of green threads, but at that point, it's both a semantic argument, and it's losing any semblance of meaning of "threaded".
Don't thank God, thank a doctor!