Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Firefox Project Could Mean Multi-Processor Support

Posted by timothy on from the but-should-a-browser-need-multi-processors dept.

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

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

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

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

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

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

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