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

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

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

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