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

34 of 300 comments (clear)

  1. As a Developer the Question I Have Is ... by eldavojohn · · Score: 5, Insightful

    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.
    1. Re:As a Developer the Question I Have Is ... by stillnotelf · · Score: 5, Funny

      Splitting your application into threads mean you have to get them to communicate with each other. When's the last time you met a programmer who loved communicating? There's nobody else in Mom's basement to practice on!

    2. Re:As a Developer the Question I Have Is ... by Chabo · · Score: 4, Insightful

      As a recent college grad, I had one course in which threads came into play; it was in the course that introduced GUI work, so our GUI wouldn't freeze while a worker thread was running, but that is the area where single-threading is most apparent to the user, after all.

      There isn't all that much room for undergrads to take courses on threading though; the course I took it in was the highest-level course that's required of all CS majors, and even still, that was only one semester after taking our "Intro to C and Assembly" course.

      Realistically, an in-depth course on good threading implementation is at the graduate level, but there isn't a large percentage of CS majors that go on to graduate work.

      --
      Convert FLACs to a portable format with FlacSquisher
    3. Re:As a Developer the Question I Have Is ... by I'mTheEvilTwin · · Score: 5, Funny

      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

      The number of cores (at least some chips) already outweighs the applications you can run if you run Winows 7.

      --
      -- This sig is in Spanish when you are not looking
    4. Re:As a Developer the Question I Have Is ... by k.a.f. · · Score: 4, Insightful

      Why isn't everyone doing this?

      Because multi-threaded programming is really really hard to get right, and because most programs either are not CPU bound, or else have so much inherently non-parallel logic that the benefit would be marginal. Serving multiple independent tabs in a web browser is extremely amenable to parallelization, but almost everything else isn't.

    5. Re:As a Developer the Question I Have Is ... by Anonymous Coward · · Score: 5, Insightful

      Erlang is a very poor choice for true multi-threaded programming. It does "lightweight" threads very nicely but real multi-CPU stuff is very slow. To the point that it negates using multiple processors in the first place.

      While I like programming in Erlang, its performance sucks donkey balls. Even the HIPE stuff is pretty damn slow.

      Plus the learning curve for functional languages is pretty high. Most programmers take a good bit of training to "get it", if they ever do. I have been programming in Erlang for about 5 years and even though I get it, I still prefer the "normal" programming languages like C/C++, Lua, Perl, whatever. I use functional tricks and I wish some of those imperative languages had more functional features but I think they work more like the human mind does and that helps me program better.

      We do need something to make multiple-CPU programming easier though. Threaded programming in C/C++ or similar can turn into a nightmare real quick, it's error prone and complicated.

    6. Re:As a Developer the Question I Have Is ... by timeOday · · Score: 3, Informative

      No, your post and the one you replied to are off base, because firefox is already multithreaded:

      # ps -eLF | grep firefox
      user 23146 20837 23146 0 1 468 496 1 15:26 ? 00:00:00 /bin/sh -c firefox
      user 23147 23146 23147 4 6 43763 59000 0 15:26 ? 00:00:12 /usr/lib/firefox-3.0.7/firefox
      user 23147 23146 23149 0 6 43763 59000 0 15:26 ? 00:00:00 /usr/lib/firefox-3.0.7/firefox
      user 23147 23146 23150 0 6 43763 59000 0 15:26 ? 00:00:00 /usr/lib/firefox-3.0.7/firefox
      user 23147 23146 23154 0 6 43763 59000 1 15:26 ? 00:00:00 /usr/lib/firefox-3.0.7/firefox
      user 23147 23146 23155 0 6 43763 59000 1 15:26 ? 00:00:00 /usr/lib/firefox-3.0.7/firefox
      user 23147 23146 23156 0 6 43763 59000 0 15:26 ? 00:00:02 /usr/lib/firefox-3.0.7/firefox

      And when I tried it just now, opening a new tab spawned a new thread (maybe more than one).

      The question for this article is, why separate processes instead of threads? If you have processes sharing memory (especially read/write memory) this distinction between threading vs. multiple processes becomes rather small.

      I do hope they can firefox survive a plugin crash, because youtube always locks up firefox eventually.

    7. Re:As a Developer the Question I Have Is ... by idontgno · · Score: 4, Informative

      Well, at least in the Unix/Linux model, processes are mostly independent, memory-wise. Shared memory is an explicit thing, under the category of Interprocess Communications (IPC). Under no condition does a fandango-on-core in one user process trash non-shared core in another process, and shared memory is generally restricted to shared-context communications, so both a smaller victim space and functionally more resilient. (Code using IPC shmem expects it to be volatile, and well-written code that uses IPC shmem vets its contents carefully before using it, so catastrophic oopses should be rare.)

      Compare that to the more modern thread model, which, in almost every architecture I'm aware of, mostly runs in exactly the same user space. If a thread eats atomic hot buffalo wings, all its brother threads in the same process get the same heartburn. The upside, barring badness, is that thread management is lightweight: no need to copy the parent memory image to a separate allocation and set up full process "OS bureaucracy" data structures. In contrast, it's practically "wave your magic wand et voila you have created a new thread". Very responsive. Very fragile.

      I think this responsiveness is a lot of the reason to love threads. And that "crashing" stuff? That never happens to me. So I don't need to worry about how fragile threads are.

      ObDisclaimer: it's been a few years since I've done any hardcore coding, so I may have missed some important details. If I did, I'm sure someone vastly smarter than me will be happy to point it out.

      --
      Welcome to the Panopticon. Used to be a prison, now it's your home.
    8. Re:As a Developer the Question I Have Is ... by CajunArson · · Score: 3, Informative

      Erlang's great until the share-nothing approach leads to so much overhead in pushing bytes back and forth between processes that you are spending more time copying bytes than actually doing work. Not saying that normal thread models are always better, but there is no "perfect" multiprocessing model and Erlang has its own pitfalls. As for Firefox, you are basically running a series of stovepipes where it makes sense for each tab to have a separate process... why it has taken so freakin' long for this I don't know, but it's not a new idea (hell I posted it right here on Slashdot back when FF3 was just coming out... lemme check.... here.

      --
      AntiFA: An abbreviation for Anti First Amendment.
    9. Re:As a Developer the Question I Have Is ... by setagllib · · Score: 3, Insightful

      There's a much more important reason to use threads instead of processes + IPC, and that's that inter-thread communication is a sub-microsecond matter. Even the context switch between multiple threads (in the same process) is so cheap you can have way too many threads and still not see the overhead if you're also doing real work. In Linux much of inter-thread communication happens entirely in userland, so you don't even suffer the cost of a system call. You can go even further and use atomic operations to make data structures and algorithms that never need system calls to begin with, and that's about as fast as you can get with threading.

      --
      Sam ty sig.
    10. Re:As a Developer the Question I Have Is ... by johanwanderer · · Score: 4, Informative

      That's because most GUI applications are driven by events, and most applications are written to have just one event handler/dispatcher.

      That doesn't mean that the application doesn't have a ton of threads or processes, utilizing processor resources. It's just easier and more efficient for a single dispatcher to communicate with a bunch of threads than it is to communicate with a bunch of processes. It also means that when one thread catches the hiccup, the whole application has to deal with the collateral damages.

      Now, to make a GUI application multi-processes, you need to have a dedicated process to handle drawing and events. Add one or more processes to handle the tasks, and IPC to tie them together. In another word, you ends up reimplementing X :)

      Add a deadline to that and you can see why you end up with just multi-threaded applications.

    11. Re:As a Developer the Question I Have Is ... by Chirs · · Score: 5, Informative

      I think you are a bit confused.

      With linux, the only difference between context-switching between threads and between processes is the update of the page tables and the flushing of the TLB. Not normally a big deal.

      Also, I'm not sure where you get the idea that interthread communication happens in userland--threads share memory, file descriptors, signal handlers, etc., but things like sockets/pipes need to go through the kernel. Processes can be made to share memory too, it's just a bit more work to set up, and you need to be explicit as to exactly what is being shared. (Which can be an advantage.)

      Perhaps you're thinking about synchronization primitives which do not require a syscall in the uncontended case--if so, those are valid to use between processes as well.

      Multithreaded apps have the potential to be faster than multi-process ones due to the lack of TLB flush, but they're more fragile due to the shared memory. For something like a browser which is often prone to crashing on crappy plugins, it makes sense to aim for reliability.

    12. Re:As a Developer the Question I Have Is ... by ckaminski · · Score: 4, Informative

      The unix fork model is nowhere near as expensive as you think - it predominantly only creates process-unix OS datastructures - it will rely on shared code pages already loaded in memory versus creating new copies.

    13. Re:As a Developer the Question I Have Is ... by buchner.johannes · · Score: 5, Funny

      )

      Sorry, I can't sleep if I know there is a bracket left open.

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    14. Re:As a Developer the Question I Have Is ... by Anonymous Coward · · Score: 4, Funny

      Lisp programmer?

  2. responsiveness by Lord+Ender · · Score: 5, Insightful

    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.
    1. Re:responsiveness by timeOday · · Score: 4, Insightful

      Multi-processing aside, I wish firefox had an option to NOT use any CPU (including scripts, plugins, etc) on tabs except the one visible. I do NOT want 30 different processes, all firefox tabs, using up all my cores just to run spam animations. Granted, I DO usually want tabs to at least download in the background, so maybe it's harder than it sounds.

    2. Re:responsiveness by Darkness404 · · Score: 3, Insightful

      Sure, but there are a lot of problems with that for the general public. For example, a lot of people (including me) fire up YouTube, Pandora, or other web-based music services in another tab then listen to the music and then browse in different tabs. I also usually open up Facebook in another tab, and like the fact that if I get a message it alerts me with a sound so I can go back to the tab.

      Sure, it would be useful as an option, but I think this is more add-on territory because of how little it would benefit most people.

      --
      Taxation is legalized theft, no more, no less.
  3. Finally! by nausea_malvarma · · Score: 5, Interesting
    About time, mozilla. I've used firefox since it came out, and lately I've noticed it's not the hot-rod it once was. The web is changing - full of in-browser videos, web apps, and other resource intensive content, and firefox has had trouble catching up. I look forward to better speed and stability, assuming this project is seen through it's completion.

    Otherwise, I'd probably switch to google chrome eventually, which doesn't have the add-on support I enjoy from firefox.

  4. I guess it can be useful in... by MoFoQ · · Score: 3, Interesting

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

  5. Catchy Name by tmmagee · · Score: 5, Funny

    How about FireFork?

    1. Re:Catchy Name by Improv · · Score: 4, Funny

      I'd mod this up if I had the points. Flames behind a fork would look really stylish... although now you've got me thinking of Fondue...

      --
      For every problem, there is at least one solution that is simple, neat, and wrong.
    2. Re:Catchy Name by can56 · · Score: 3, Funny

      Flames, Forks, and Fondue makes me think of Hell's Kitchen and Gordon Ramseys logo.

  6. The problem is not threads vs processes... by faragon · · Score: 3, Insightful

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

    1. Re:The problem is not threads vs processes... by MBCook · · Score: 4, Insightful

      Until Mozilla has control over Flash, most internet uses will have to put up with buggy plugins. This is about being defensive instead of just getting shot.

      --
      Comment forecast: Bits of genius surrounded by a sea of mediocrity.
    2. Re:The problem is not threads vs processes... by entgod · · Score: 3, Insightful

      But why should flash crashing take down all of firefox? Why couldn't we just encapsulate flash in it's own process or something?

  7. the real question is... by Tumbleweed · · Score: 3, Interesting

    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.

  8. Interest dynamic between Firefox and Chrome: by darpo · · Score: 4, Insightful

    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.

  9. I kind of like single-processor apps. by Sowelu · · Score: 4, Insightful

    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.

    1. Re:I kind of like single-processor apps. by Eunuchswear · · Score: 4, Insightful

      If a process using 100% of your cpu "cripples" your machine your OS is broken,

      --
      Watch this Heartland Institute video
  10. A funny answer, but it's also the serious one by whiledo · · Score: 3, Insightful

    Because it's hard?

    --
    Moderators: Before moderating a comment Insightful/Informative, check to see if a child post has already refuted it.
  11. Re:How about threads? by TheRaven64 · · Score: 3, Interesting
    No. Just no.

    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
  12. Re:How about threads? by RiotingPacifist · · Score: 3, Interesting

    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!
  13. Re:Relief by Iguanadon · · Score: 3, Informative

    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.