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.

Comments

Re:So sad...

[TofuMatt]

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.

Re:About time

[anaesthetica]

According to the Ars coverage:

Mozilla has explored the possibility of adopting a multiprocessing approach for Firefox in the past, but the idea didn't gain serious traction in the Firefox developer community until it was implemented by Google and Microsoft in their respective web browsers.

It was probably too large a project to consider doing without a pressing need. Chrome and IE8 supplied that pressure.

Re:Humiliated By Google's Chrome

[debrain]

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.

Does that mean distributed XPCOM?

[DrXym]

Most of Gecko is bound together with interfaces defined in IDL and implemented in C++ / JS. This model is called XPCOM and is based off Microsoft's COM in a large part. In theory (though not always in practice), it didn't matter in COM where the interfaces are implemented - single thread, multi-thread, multi-process or even across a network so long as the caller and callee abide by things such as rules for memory allocation, reference counting, object creation etc. I say in theory because some interfaces can be horribly inefficient when called repeatedly over a network, some interfaces might have broken IDL definitions and some interfaces might deal with things like handles or memory addresses which don't translate properly between processes.

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.

Re:Nice

[anaesthetica]

Yes, they were. TraceMonkey was started in earnest in early summer 2008. Chrome was (accidentally) announced 1 September 2008.