Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Firefox To Get Multi-Process Browsing

Soulskill posted about 5 years ago | from the multi-fox dept.

Mozilla 383

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.

cancel ×

383 comments

lol (-1, Offtopic)

Anonymous Coward | about 5 years ago | (#28624851)

First post?

About time (1, Insightful)

WuphonsReach (684551) | about 5 years ago | (#28624855)

What took so long?

Re:About time (5, Funny)

Anonymous Coward | about 5 years ago | (#28624995)

What took so long?

Yeah! All they had to do was change their entire codebase from around 5+ years of Firefox (and probably more of Mozilla/Netscape) to update it! That's, what, half an hour's work? And don't give me this "legacy code" bullshit; if they bothered to anticipate our fifty bajillion core processors back then like any NORMAL person should today, they wouldn't be in this mess!

Lazy bastards. I mean, how hard is it to change what is apparently that one really trivial-to-find call in their code to useProcessSeparationOhAndIAlsoWantAPony(true)? Took them long enough...

Re:About time (5, Funny)

Ethanol-fueled (1125189) | about 5 years ago | (#28625157)

Really. And all this wouldn't even be a problem if they just wrote it in Java to begin with.

This is why we can't have nice things.

Re:About time (-1, Flamebait)

Anonymous Coward | about 5 years ago | (#28625597)

Get the Java dick out of your ass please. That's what we need, Firefox more hideous than it currently is.

hey... (2, Funny)

whopub (1100981) | about 5 years ago | (#28625881)

Get the Java dick out of your ass please.

Hey, leave the other dude alone and wait for your turn.

Re:About time (0)

Anonymous Coward | about 5 years ago | (#28625213)

Lazy bastards. I mean, how hard is it to change what is apparently that one really trivial-to-find call in their code to useProcessSeparationOhAndIAlsoWantAPony(true)? Took them long enough...

The real problem was solving all the side-effects of the OMG_PONIES callback. Trying to pass that through inter-process channels makes almost all OS kernels throw a SIGRETARDED and kill() the entire process tree. Sad, but true.

Re:About time (5, Interesting)

maxwell demon (590494) | about 5 years ago | (#28625259)

They had to chance a code base from around 5+ years only because they didn't things right 5+ years ago. Remember, back then they were doing a complete code rewrite anyway.

And no, the true reason to do this is not multicore. That it also gets faster on multicore is just a nice side effect. The true reason to do it is stability. If one page makes problems, you don't lose all the others. This was indeed even more important back when browser and mail was the same program, because it meant that a page crashing your browser could destroy your almost-completed email, too (yes, this has happened to me, although I'm not sure if it was still old Netscape or already new Mozilla). Of course, today it's quite possible that your browser is your mail client again because you're using webmail.

Note that if it were just a performance thing, they could have gone multithreaded instead. This would probably get even better performance.

Re:About time (2, Interesting)

Andy Dodd (701) | about 5 years ago | (#28625711)

This should solve a long-standing bug regarding proxies and DNS.

For whatever reason, if you are using a proxy server (It may only pertain to specific proxy configurations, I'm not sure, I do know that the proxy setup where I work triggers this bug), the whole browser will freeze while a DNS lookup executes. NOT good if you accidentally typo a domain.

Re:About time (2, Informative)

anaesthetica (596507) | about 5 years ago | (#28625725)

Funny thing is, they're already in the middle of a major revision project. After Fx2, Brendan Eich released a set of goals for Mozilla 2 [mozillazine.org] . The idea is/was to do a large scale cleanup and refactoring (explicitly not a rewrite, however) in order to get rid of some legacy code still around from overly ambitious plans that didn't pan out (e.g. XPCOM). That was to happen in parallel to the development of Fx3 on Gecko 1.9.0.

It's not clear how much progress has been made on Gecko 2.0—almost no public-facing announcements are made about it to the community, and the wiki page [mozilla.org] is dormant. All the work and focus seems to have been poured into Gecko 1.9.1 (Fx3.5) and now 1.9.2 (Firefox.next).

One element of Eich's vision for Mozilla 2 was implemented in 3.5 – the new faster javascript implementation. But the smaller, leaner, more approachable codebase goal? Who knows.

Now it seems they're attempting 'Electrolysis [mozilla.org] ' (the codename for process separation) in parallel to the development of Firefox.next (Gecko 1.9.2), which is already ostensibly being done in parallel to the Mozilla 2 refactoring. Makes you wonder if there's anyone at the wheel.

Here's an essay I wrote about Mozilla's direction [kuro5hin.org] back in 2007 when Mozilla 2 was supposed to kick off.

Re:About time (1)

RebelWebmaster (628941) | about 5 years ago | (#28625831)

I think the plan for Gecko 2.0 has changed since Brendan's post a couple years ago, shifting in favor to smaller, incremental improvements with shorter lead times instead of long, drawn-out changes creating release gaps like the one between 2.0 and 3.0.

Re:About time (2, Insightful)

IntlHarvester (11985) | about 5 years ago | (#28625863)

They had to chance a code base from around 5+ years only because they didn't things right 5+ years ago. Remember, back then they were doing a complete code rewrite anyway.

Actually it was more like 10 years ago :/

And you're right -- Internet Explorer 4 had a multiprocess model (one process per window), but Mozilla insisted on having everything running in the same process, even the frickin mail client.

A lot of people questioned this at the time, but the response was "That's the way Netscape Communicator 4 does it and everyone loves Netscape 4".

Re:About time (2, Informative)

Jurily (900488) | about 5 years ago | (#28625467)

if they bothered to anticipate our fifty bajillion core processors back then like any NORMAL person should today, they wouldn't be in this mess!

Processes don't offer more multicore support than threads. What they do offer is clean separation of code that can run independently.

This has nothing to do with multi-core CPUs (1)

RingDev (879105) | about 5 years ago | (#28625761)

I've been doing this exact same work since the mid-90's. Anytime you have a processor intensive or I/O task in a Windows environment, it should be moved off of the primary thread. Even if the process is being run on a single core processor the UI will still be responsive (albeit possibly laggy) while the I/O and calculation is running.

-Rick

Re:About time (3, Funny)

Krneki (1192201) | about 5 years ago | (#28625095)

Most of the people are still running a single core CPU.
And if we could remove Adobe Flash player we would never need a second CPU.

Re:About time (4, Informative)

abigor (540274) | about 5 years ago | (#28625211)

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.

Re:About time (3, Informative)

Anonymous Coward | about 5 years ago | (#28625275)

>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.

Re:About time (4, Informative)

Vectronic (1221470) | about 5 years ago | (#28625325)

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.

Re:About time (1)

Krneki (1192201) | about 5 years ago | (#28625383)

My mistake. :/

Re:About time (-1)

Beardo the Bearded (321478) | about 5 years ago | (#28625495)

It's not a question of multi-core architecture. No commercial program on earth takes advantage of more than two cores, not even the high-end drafting programs on mirrored quad Xeons.

So this multi-process browsing makes the underlying code behave the way Firefox looks like it behaves. What you get is each tab or each window spawning its own process - or runtime space - in the OS. This keeps them from interfering from each other under normal circumstances.

This means that while you're waiting for a Flash player to load the rest of your tabs will keep working. (For example, if you're using Ubuntu and you want to see something on Youtube.) If one website freezes or crashes, you don't get every tab and window thrown out.

Mods, the parent's Offtopic rating is unfair. He's simply mistaken about terminology.

Re:About time (0)

Anonymous Coward | about 5 years ago | (#28625673)

My compiler uses all four of my cores. Does that not count as a commercial program?

Re:About time (2, Informative)

Vectronic (1221470) | about 5 years ago | (#28625833)

No commercial program on earth takes advantage of more than two cores...

What? Yes, even some of the "high-end drafting" programs do, every single 3D Modeling and/or Drafting application I have, can use 1, 2, or 4 (and likely upwards, but the highest core/CPU PC I have is 4) as they see fit.

Operating Systems are a "commercial program", and most of them can handle 8, 16, 32 or more processors.

If you have information as to otherwise, I'd be highly interested.

Re:About time (5, Informative)

anaesthetica (596507) | about 5 years ago | (#28625113)

According to the Ars coverage [arstechnica.com] :

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:About time (2, Interesting)

MrMista_B (891430) | about 5 years ago | (#28625253)

Wow. The Firefox developer community really doesn't care much for its users, does it? I've interacted with them in small ways in the past, and this verification of my suspicions only supports the dim view I take of them.

Re:About time (4, Insightful)

anaesthetica (596507) | about 5 years ago | (#28625823)

This is a pretty ungenerous view to take. First off, the Mozilla community is not confined to geeks on Slashdot who care passionately about things like process separation. The Firefox developer community most certainly does care about its users, but the users don't necessarily know that they want, much less could benefit from, process separation. Like Henry Ford said, "If I had asked people what they wanted, they would have said faster horses." So, Firefox developers delivered what the mass base of users wanted. If anything, you might fault them for being overly user-driven. We can see this in their focus on adding new features, instead of leaving the trivial features as extensions and focusing on performance, standards implementation, and technical features like process separation.

Re:About time (3, Insightful)

Rufty (37223) | about 5 years ago | (#28625859)

The Firefox developer community cares a lot for its users ... compared to the Thunderbird developer community.

Re:About time (1)

QuantumRiff (120817) | about 5 years ago | (#28625373)

I also read a discussion once about how it would involve a TON of work to get the extensions working properly again.

Re:About time (1)

Volante3192 (953645) | about 5 years ago | (#28625437)

I'd be worried how plugins work across multiple processes. Do we run an addon seperately for each process? Do they all load under the firefox process? Can we crash an addon in one process and not have it bring down other processes?

Chrome and IE have the benefit of not dealing with those questions.

Re:About time (1)

Tumbleweed (3706) | about 5 years ago | (#28625627)

I'd be worried how plugins work across multiple processes. Do we run an addon seperately for each process? Do they all load under the firefox process? Can we crash an addon in one process and not have it bring down other processes?

Chrome and IE have the benefit of not dealing with those questions.

Sure, cuz there aren't any real add-ons for Chrome yet that don't involve manually installing them via a rather tedious process.

When Flash crashes in Chrome, it crashes in every tab IN Chrome (though it doesn't take out Chrome itself).

I'd like FF to do this better than Chrome - give me the option to run Flash player in each tab separate from Flash player in every other tab. That'd be nice.

Re:About time (0)

Anonymous Coward | about 5 years ago | (#28625693)

And adding to their reputation as memory hogs...

Re:About time (1)

Tumbleweed (3706) | about 5 years ago | (#28625789)

And adding to their reputation as memory hogs...

The memory hogging is a thing of the past as of FF v3.5. It now uses the least memory. It's pretty nice, though Flash seems to have even more problems on this version of FF than before. *sigh*

Re:About time (5, Funny)

Tumbleweed (3706) | about 5 years ago | (#28625561)

It was probably too large a project to consider doing without a pressing need.

Cuz yeah, Flash locking up the entire browser wasn't a pressing need until IE8 and Chrome. Riiiight.

LOTS of us have been asking about this for a VERY long time (years). Leaving it this late is called 'lack of vision'. This should've been in the very first version. Now there IS a ton of code to make this work with. I imagine that's why they call this Electrolysis...it's a hairy problem now that it's been ignored for so long.

Re:About time (1)

metamatic (202216) | about 5 years ago | (#28625839)

Now, if only we can get Chrome to have a simple UI for per-site cookie and script preferences, maybe they'll finally add that feature to core Firefox.

Re:About time (1, Funny)

Anonymous Coward | about 5 years ago | (#28625209)

Great. Now firefox can consume 1GB of memory in each of four separate processes. Guess I'll have to add more memory...

Re:About time (1)

Tanktalus (794810) | about 5 years ago | (#28625297)

It's called copy-on-write technology. It means that 1GB+1GB+1GB+1GB will total about 1.2GB. It's advanced math.

Re:About time (0)

Anonymous Coward | about 5 years ago | (#28625541)

It also means that every write after a fork gets a page fault, which is not exactly cheap. Each new tab you create would make the entire browser slower for a period of time.

Re:About time (0)

Anonymous Coward | about 5 years ago | (#28625843)

It also means that every write after a fork gets a page fault

Only on non-shared pages (I.e. I would ass-u-me that they are doing a shared mmap() segment for accessing stuff like the cache). The data & text segments obviously never get written, so those's never COW'd. So that leaves...the stack.

Re:About time (1)

Wowsers (1151731) | about 5 years ago | (#28625589)

When Firefox locks-up in Linux, which process do you kill? Should be fun to issue the kill command to who knows how many Firefox entries just to kill it completely and avoid the "An instance of Firefox is still running" problem.

Re:About time (3, Funny)

Captain Segfault (686912) | about 5 years ago | (#28625713)

That sounds like a job for killall!

Re:About time (0)

Anonymous Coward | about 5 years ago | (#28625681)

If it weren't for all the extensions, this bug would have been enough to get me to abandon Firefox. It is a well-known UI design principle that the GUI thread of an application should not be given long-running tasks.

It drives me nuts when I accidentally type an invalid address in Firefox. Typically, I know about it the split-second after I press enter, but Firefox kindly prevents me from hitting the Stop button for at least 5 seconds while it figures out all on its own that the address is invalid.

Personally, I'd prefer to see multi-threading instead of using multiple processes, but either way, it's about time this gets fixed. Firefox's current behavior is unacceptable for an application with such a large user and developer base.

Re:About time (1)

GMFTatsujin (239569) | about 5 years ago | (#28625957)

They were waiting for the tab to finish loading.

Nice (3, Insightful)

suso (153703) | about 5 years ago | (#28624885)

This is cool. Competition is good.

Humiliated By Google's Chrome (4, Insightful)

Anonymous Coward | about 5 years ago | (#28625279)

The clowns working on Firefox had years, YEARS, to get their act together and rewrite the STINKING PILE OF SHIT that is the Firefox codebase. But they chose to flame anyone who dared talk about the massive architectural problem in the absurdly outdated Firefox process model.

Memory protection for each tab? Not possible! Stop asking for something that can't be done! They cried!

Threading for Javascript? Not possible! Stop asking for something that can't be done! The Firefox devs cried!

That is why those AC posts from Firefox devs were so vicious and venomous for everyone pointing out the massive memory/resource leaks in Firefox that have only been somewhat lessened in the latest versions. The solution for those problems involves a complete rewrite of the process and memory model for Firefox.

Now Google came out and humiliated the Firefox devs with Chrome and its amazing realworld threaded Javascript and memory and process protection/isolation.

Nothing but pity and absolutely no sympathy for anyone faced with retrofitting Firefox into a semblance of a modern browser architecture.

Now with full extension support in Chrome this is like hearing about Microsoft scrambling to fix their massive security problems in IE long after you dumped it.

Re:Humiliated By Google's Chrome (5, Informative)

debrain (29228) | about 5 years ago | (#28625629)

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 [mozilla.org] .

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.

Re:Humiliated By Google's Chrome (4, Insightful)

suso (153703) | about 5 years ago | (#28625697)

Hey chill, give em a break. There is something to be said for filtering out every little feature request that gets sent your way. Good filters are how great software stays great (like Linux) and makes sure that the project doesn't veer in the wrong direction. I don't know much about the Firefox developers, but I'd say they have good reason to be filters for a lot of things.

As a sysadmin, I deal all the time with users asking for the latest features, but I have to weigh which ones can be done now, which ones have to wait and which ones shouldn't be done because they are stupid. I try to keep an open mind, but sometimes you get stuck in a rut because of old information or "the way things used to work", so you just have to be patient, try to show the new way and hope that it sinks in.

Re:Humiliated By Google's Chrome (4, Insightful)

Blakey Rat (99501) | about 5 years ago | (#28625769)

They're not doing it because Chrome has it, they're doing it because IE8 has it. Microsoft putting this in Internet Explorer before Firefox is basically equivalent to kicking Firefox developers in the nuts.

Re:Nice (1)

mr crypto (229724) | about 5 years ago | (#28625411)

They should call it skulk [wiktionary.org] ...

I love how.. (-1, Offtopic)

sys.stdout.write (1551563) | about 5 years ago | (#28624891)

Mozilla is playing catch-up to Google in this regard.

How long until a Mozilla Firefox OS is announced?

Re:I love how.. (2, Insightful)

LizardKing (5245) | about 5 years ago | (#28624967)

They've effectively been there already. It was when Netscape started talking about the browser being the "new desktop" that Microsoft started to see them as a serious threat. Cue the purchase of Spry Mosaic, its rebranding as Internet Explorer and attempt to extinguish Netscape by bundling it with Windows.

Linux users are fucking bastards (-1, Troll)

Anonymous Coward | about 5 years ago | (#28624921)

If you are a linux user you deserve your penis to be covered in bees [encycloped...matica.com]

Also MS willl come out with its replacement for , the ActiveX video plug in so firefox can fuck off.

Processes, processes, processes! (2, Funny)

jeffb (2.718) (1189693) | about 5 years ago | (#28624935)

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.

This sentence was a little hard to process.

(I note that the "process" of Slashdot incremental improvement has now reached a point where clicking anywhere in the text-entry box causes the box to LOSE focus. If you don't want us using Safari, there are more efficient ways to get us to move.)

Re:Processes, processes, processes! (1)

ChefInnocent (667809) | about 5 years ago | (#28625885)

I thought they didn't want us to use IE.

Rickrolling. (-1, Offtopic)

itai.saku.kusari (1222274) | about 5 years ago | (#28624937)

No more rickrolls to have to abort all of firefox! :D

That's good (3, Funny)

Junior J. Junior III (192702) | about 5 years ago | (#28624963)

I was concerned that Firefox wasn't using as much of my system's RAM as it could. I bought 8GB, and I intend to use it.

In all seriousness, this is good. It should handle crashes and frozen processes better, like Chrome.

Thanks google, and thanks mozilla, for helping to drive competition and make the web browser better.

Re:That's good (0)

Anonymous Coward | about 5 years ago | (#28625143)

Not to mention drive consumers to purchase more of said RAM.

So sad... (0, Interesting)

Anonymous Coward | about 5 years ago | (#28624971)

...to see Firefox desperately jumping on the multithread bandwagon. Yes, of course restarting your browser once about every month is a terrible pain in the butt. Takes a long time too! I'm thinking: they didn't design for this from the start, so implementing it now will not be worth the headaches caused by unforseen issues.

Re:So sad... (5, Informative)

TofuMatt (1105351) | about 5 years ago | (#28625079)

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:So sad... (1)

BlueCollarCamel (884092) | about 5 years ago | (#28625935)

You intentionally browse to bring down all your tabs and windows?

Re:So sad... (2, Insightful)

Thiez (1281866) | about 5 years ago | (#28625203)

The 'multithread bandwagen'? Multithreading is not just some temporary hype that will be gone and forgotten next year. It is A Good Thing. If they get it right it'll be a big improvement to the browser.

Having said that, your concerns that it may be a pain to implement in a browser that was not designed to support them are valid. While I expect them to succeed, you can always stick with an older (single-threaded) version for a while while the most problematic bugs get fixed.

Re:So sad... (-1, Flamebait)

FishWithAHammer (957772) | about 5 years ago | (#28625367)

Except that this has nothing to do with threading at all.

You know, there was a time Slashdot actually had posters who weren't as fucking dumb as you are.

Re:So sad... (1, Funny)

vlm (69642) | about 5 years ago | (#28625535)

.... said the six digit UID to the seven digit UID.

Re:So sad... (1)

DMUTPeregrine (612791) | about 5 years ago | (#28625591)

Firefox is already multithreaded. This is multiprocessing, which is different. Threads are subsets of a process, and if a thread crashes the whole process crashes. This will allow one process (tab) to crash without crashing the entire browser. Each process (tab, UI) can be multithreaded, allowing for performance gains.

The downside, of course, is that processes generally require more overhead than tabs.

Restart Firefox Only Once A Month??? LOL! (0)

Anonymous Coward | about 5 years ago | (#28625369)

Before I dumped Firefox months ago I would have to quit the piece of shit browser 2 to 3 times a day to clear out the crud that gets left behind with every minute of use.

The only people pathetic enough to put up with such a piece of junk app are people who still think they are being cool and impressing others with "I'm kewl, I use Firefox, not IE!"

Re:Restart Firefox Only Once A Month??? LOL! (3, Insightful)

hedwards (940851) | about 5 years ago | (#28625617)

If that's the case, then you were doing something wrong. Firefox rarely uses more than 300mb of memory on my machine and tends not to crash either definitely not 2 to 3 times a day. Also, if you're only using it for 2 or 3 minutes a day, you're clearly doing something specifically to make it crash, because I've had this window open for multiples of that time right now and it has yet to crash

It's become common place for people to blame Firefox for things like Flash crashing or the gunk that comes from browsing. I've been browsing for some time with noscript and without flash and I rarely end up with this kind of trouble. On top of that I have the cache, cookies and history cleared upon exit. And I'm not having any sort of trouble of the sort you're describing.

I don't mind people criticizing Firefox, but this immature trolling because of your own incompetence is enough to make one slightly annoyed.

Re:So sad... (0)

Anonymous Coward | about 5 years ago | (#28625399)

Netscape Navigator just called...

Re:So sad... (1)

funkatron (912521) | about 5 years ago | (#28625475)

I would already expect it to be multithreaded, otherwise waiting for the network would slow down other parts of the browser. The changes proposed are a move to a multi-process model where each tab is unable to interfere with the rest of the browser, effectively constraining any problems to the tab in which they occur.

Nice of them to announce that (0)

Pentium100 (1240090) | about 5 years ago | (#28625015)

Now I'll know that before updating Firefox I have to carefully read the "what's new in version x.y" part.

Once again (-1, Flamebait)

Anonymous Coward | about 5 years ago | (#28625027)

The Firefox browser has never inovated. It has not brought anything new.Tabbed browsing, private mode, multi-process tabs, etc. Everything -- really -- everything was copied by Mozilla from a competing browser. Add to it that it is awfully slow and you get the worst browser in the field.

I think I prefer a single process (1)

89cents (589228) | about 5 years ago | (#28625047)

Yes, back in the days when a bad web page would crash your browser this was bad, but I have not seen those crashes recently. If the browser is stable, what benefit do multi-processes have? Multiple Firefox processes seems like unnecessary overhead. Also, and maybe I should read the details, but if I am authenticated to a website in one tab, does that authentication carry over to other tabs using other processes?

Re:I think I prefer a single process (0)

Anonymous Coward | about 5 years ago | (#28625101)

I'd prefer multiple threads (and a single process) over multiple processes.

-V

Re:I think I prefer a single process (1)

runningduck (810975) | about 5 years ago | (#28625333)

There shouldn't be too much overhead being most modern OSs use shared code pages and copy on write memory management.

While pages generally do not crash browsers plug-ins do! By launching the plug-ins with the page rendering process the browser should be able to isolate and minimize the impact.

If the engineers design the changes intelligently all the page metadata should remain within the parent process. This greatly simplifies caching and coherency--which they appear to be discussing in the article. The only components that should be pushed into the child processes are things which execute uncontrolled and untrusted content.

Re:I think I prefer a single process (4, Interesting)

Millennium (2451) | about 5 years ago | (#28625335)

Yes, back in the days when a bad web page would crash your browser this was bad, but I have not seen those crashes recently.

Do you run a lot of plug-ins, by any chance? Browser makers don't control plug-in code (other than the code for their own plug-ins, of course), but this code is still capable of taking out a browser process if it goes bad.

If the browser is stable, what benefit do multi-processes have?

The other big benefit is that one process can't hog the CPU: even if one page gets into a ridiculously tight JavaScript loop that bogs that page down, the others should continue to load.

Still, the "if the browser is stable" issue is a very big if, and as I mentioned above, it's not completely under the browser maker's control.

Also, and maybe I should read the details, but if I am authenticated to a website in one tab, does that authentication carry over to other tabs using other processes?

It depends on how the browser is written, but it can be done.

Re:I think I prefer a single process (1)

The Moof (859402) | about 5 years ago | (#28625393)

I would prefer multiple processes, especially for things like plugin support. Nothing like watching one poorly written swf hose all of your browsers for a minute. Also, there are still a few javascript tricks to lock the browser, forcing a manual kill. It'd be nice to just kill the offending process instead of killing everything.

Re:I think I prefer a single process (1)

ShadowRangerRIT (1301549) | about 5 years ago | (#28625429)

On *Nix systems, process creation overhead is low enough, and thread cost high enough, that the perf hit will probably be negligible. Problem is, Windows tends to do poorly on process creation, while handling multi-threading fairly well.

In both cases, the costs are seen at creation time (I haven't looked into whether the scheduler for each is optimized for one or the other). This does mean that a multi-tab bookmark (like my 30 webcomic bookmark at home) may start taking noticeably longer to load on Windows machines. Then again, it seems to have slowed down slightly in FF 3.5 anyway (that may be just a UI change though, it's not like I read them all inside of five seconds).

Of course, I'd also like to see browsers and plugins go 64 bit; the built-in nulls in memory addresses make buffer overruns much harder to exploit, and I'd prefer they work on security for a little.

Re:I think I prefer a single process (0)

Anonymous Coward | about 5 years ago | (#28625441)

Bingo. An increase in the number of moving parts needed to render a frickin' web page is a really dumb idea.

Re:I think I prefer a single process (1)

FishWithAHammer (957772) | about 5 years ago | (#28625443)

You've missed many things.

Just because you aren't crashing Firefox doesn't mean that it doesn't still crash very often.

The authentication store is controlled by the master process so other tabs can access it (at least in Chrome, though given Mozilla's determination to fuck up I would not be surprised if they had problems with this).

It only appears to be unnecessary overhead because you don't know what's going on. Try to keep up.

Why a process? Surely a thread would scale better? (1)

H0p313ss (811249) | about 5 years ago | (#28625069)

Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all. Why not just have rendering worker threads? Have I missed something?

Re:Why a process? Surely a thread would scale bett (2, Interesting)

Anonymous Coward | about 5 years ago | (#28625227)

They want separate processes as a crutch to deal with memory leaks ... the idea being the leak would be contained to one tab's own process rather than the entire browser, and when you close the tab, you close the process.

Re:Why a process? Surely a thread would scale bett (1)

EvanED (569694) | about 5 years ago | (#28625265)

The biggest problem nowadays isn't memory leaks but rather fragmentation.

Of course, the multiprocess architecture helps with that too.

Re:Why a process? Surely a thread would scale bett (1)

EvanED (569694) | about 5 years ago | (#28625231)

Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all.

Chrome does it on Windows and it's okay.

Why not just have rendering worker threads?

There are two benefits to switching to this. First, it will become more responsive as one tab is much less likely able to eat CPU for a while and delay others (something that happens to me enough I have to restart Firefox for that reason every day or two). But the second reason is that if one tab causes a crashing bug to manifest, it is much harder to bring down the whole browser, and instead it just brings down that tab.

Threading gives you the first benefit, but not the second. Processes give you both.

I'm not sure how important the second reason is, but I do get crashes from time to time because of Flash.

Yup... fashion (1)

Colin Smith (2679) | about 5 years ago | (#28625257)

Security

Speed ----------- You are here.

Security ----------- The rest of the world is here.

Speed

Need to catch up mate. We'll be getting rid of virtual machines next too.

 

Re:Why a process? Surely a thread would scale bett (2, Informative)

Millennium (2451) | about 5 years ago | (#28625269)

Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all.

The Microsoft folks don't seem concerned about this, at least not concerned enough to implement it in IE. While I don't doubt that Windows processes are fairly heavyweight, I doubt that they're big enough to cause trouble until the user has hundreds of tabs open.

Why not just have rendering worker threads? Have I missed something?

Although working in multiple threads can increase performance in much the same way that multiple processes can, that's not the major benefit of the multi-process architecture. The big benefit to multiple processes is that if one of them dies for some reason, the other processes don't go down, and so the user can (mostly) continue to work. Threads can't do this, because all the threads are still part of a single process.

Re:Why a process? Surely a thread would scale bett (0)

Anonymous Coward | about 5 years ago | (#28625427)

The Microsoft folks don't seem concerned about this, at least not concerned enough to implement it in IE.

It's implemented in IE8.

Re:Why a process? Surely a thread would scale bett (1)

H0p313ss (811249) | about 5 years ago | (#28625855)

The Microsoft folks don't seem concerned about this, at least not concerned enough to implement it in IE.

It's implemented in IE8.

You mean render threads right?

Re:Why a process? Surely a thread would scale bett (1)

EvilRyry (1025309) | about 5 years ago | (#28625295)

That doesn't solve the stability problem. If one of those worker threads does something naughty, the whole process is going down.

Although process creation time on Windows is slow compared to other OSes its more than fast enough for spawning a process per tab. Chrome and IE8 have already proved this in the real world.

Re:Why a process? Surely a thread would scale bett (1)

FishWithAHammer (957772) | about 5 years ago | (#28625455)

Process creation is much cheaper under Windows than it used to be.

And one crashed thread takes out all the threads, resulting in--gasp!--the current situation, as Firefox's tabs are nominally multithreaded.

Process segmentation is the only way to retrofit that bad codebase into actually some sort of working order when compared to IE8 and Chrome. It should also help their astonishing memory leaks too.

Re:Why a process? Surely a thread would scale bett (1)

Tumbleweed (3706) | about 5 years ago | (#28625663)

Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all.

Yeah, cuz multi-process Chrome on Windows is such a piece of shit?

Re:Why a process? Surely a thread would scale bett (1)

H0p313ss (811249) | about 5 years ago | (#28625925)

Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all.

Yeah, cuz multi-process Chrome on Windows is such a piece of shit?

This is purely anecdotal... but as far as I can tell for my daily usage Chrome is no faster than Firefox 3.5 with adblock. (Adblock ftw)

Nice (4, Interesting)

Craig Davison (37723) | about 5 years ago | (#28625223)

Competition from Chrome was a good thing: first the Javascript improvements, now separate processes for the plugins.

Re:Nice (3, Informative)

ShadowRangerRIT (1301549) | about 5 years ago | (#28625469)

Correct me if I'm wrong, but wasn't Firefox working on JS speed before Chrome was announced?

Re:Nice (1)

RebelWebmaster (628941) | about 5 years ago | (#28625895)

Yes

Re:Nice (1)

two basket skinner (1288246) | about 5 years ago | (#28625587)

separate plugins might improve security but if they aren't careful, all those heavy-weight process will tie up resources. Ive never looked at the code but this was my first impression of chrome last year, though that impression has changed over time. Heres to hoping the firefox team learns from chrome

Will this benefit the average user? (3, Insightful)

DutchUncle (826473) | about 5 years ago | (#28625395)

For users with anything pre-multi-core (and that's only a few years old), this will result in things getting *slower* because of the process overhead. I hope it senses resources and optimizes appropriately, or all of the friends and relatives I tech-support will be cursing me when the update happens. Some of them are already ticked that when they double-click on the Firefox icon, it takes longer to load than IE because of all the update-phone-home (the sort of thing for which we would all get annoyed at M$).

Eventually we'll get to the point where the window comes up and it takes a ludicrous time to fill . . . just like Windows already does now.

Better philosophical architecture is a good thing. Running well in the practical typical system, in front of the average user, is good too. Disruptive change is not always the way to please your users.

'Allocating resources and optimizing appropriately (0, Flamebait)

MrMista_B (891430) | about 5 years ago | (#28625647)

Are you kidding? This is the Firefox dev team. Of course they won't. They'll say it's impossible, and call you an idiot for even thinking of suggesting something like that. Not until someone Microsoft or Google does it, will they feel any need to implement something so useful.

Re:Will this benefit the average user? (4, Informative)

Eric52902 (1080393) | about 5 years ago | (#28625735)

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.

Re:Will this benefit the average user? (1)

SpinyNorman (33776) | about 5 years ago | (#28625869)

No, there's no reason to assume it'll be slow, unless they just screw up the implementation.

If you're really worried about process creation overhead, then just create a pool of processes and reuse them.

More to the point, do have any idea how absurdly fast today's processors are compared to things like process creation. Exactly how long do you imagine it to take to create one? Long enough for you to notice?!!

Will this help with flash crashing my Ubuntu? (0)

Anonymous Coward | about 5 years ago | (#28625415)

So will this also run those forks with niceness values that wont cause flash to make my Ubuntu machine unable to register mouse movements or keystrokes (effectively leaving a reboot as the only option) for poorly written flash applications?

The "About Time" Bandwagon (4, Insightful)

CannonballHead (842625) | about 5 years ago | (#28625605)

I'll bite. It's about time.

Even explorer.exe is able to open directories using different processes, if you want. Frankly, I found it frightfully annoying to have X+ tabs open and have ONE of those tabs cause the entire program to crash, usually due to a plugin issue. Made no sense to me. Multi-process/multi-threaded/multi-whatever programming has been around for quite a while now, and multi-core cpus have been pretty common, too.

It's one of the huge advantages that I saw with Chrome (over Firefox). That and program open/new tab open speed. FF 3.5 seems to have addressed this somewhat, but it's still slower, I think.

Hooray for competition, and hooray for finally taking advantage of the hardware out there. Really, for one of the most used applications someone will use, it seems silly to only allow it to use a single-process model.

Does that mean distributed XPCOM? (5, Informative)

DrXym (126579) | about 5 years ago | (#28625669)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...