New Firefox Project Could Mean Multi-Processor Support 300
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."
Re:How about threads? (Score:2, Informative)
or am I wrong about it being multithreaded?
Re:As a Developer the Question I Have Is ... (Score:2, Informative)
As chipmakers demo 64 or 128 core chips, why aren't we coding and being trained in Erlang?
Every mainstream programming language has facilities for multithread programming and there's no need to learn a new one just to do it.
Why aren't schools teaching this as a mandatory class?
Multiprocessing is a key theme of operating systems courses, which are in the core curriculum of all CS programs. Many other courses also cover synchronization primitives, IPC, and other topics useful for multithreaded programming.
Why aren't old applications being broken down and analyzed to multithread components that don't interact?
It's usually difficult to retroactively add such features to applications that weren't originally designed with them in mind.
Why isn't the compiler theory concentrating on how to automate this (if possible)?
Compilers do parallelize when possible. It's usually not possible without intervention by the programmer.
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?
It is a major issue in modern 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.
Yup.
Re:As a Developer the Question I Have Is ... (Score:4, Informative)
No, your post and the one you replied to are off base, because firefox is already multithreaded:
# ps -eLF | grep firefox /bin/sh -c firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox
user 23146 20837 23146 0 1 468 496 1 15:26 ? 00:00:00
user 23147 23146 23147 4 6 43763 59000 0 15:26 ? 00:00:12
user 23147 23146 23149 0 6 43763 59000 0 15:26 ? 00:00:00
user 23147 23146 23150 0 6 43763 59000 0 15:26 ? 00:00:00
user 23147 23146 23154 0 6 43763 59000 1 15:26 ? 00:00:00
user 23147 23146 23155 0 6 43763 59000 1 15:26 ? 00:00:00
user 23147 23146 23156 0 6 43763 59000 0 15:26 ? 00:00:02
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.
Re:How about threads? (Score:3, Informative)
Do mods know nothing abuot modern operating systems?
A properly implemented application using a multi-process model should use only slightly more memory, thanks to shared memory [wikipedia.org], a feature of any modern operating system.
Re:responsiveness (Score:2, Informative)
Um, IE8 does the exact same thing. It uses child processes to control groups of tabs by domain.
Of course, IE8 was doing it since the first public beta, over 5 months before anyone knew about Chrome. The implementation in Chrome is a near carbon copy. Who is copying whom?
Re:How about threads? (Score:3, Informative)
If it is threads, then the common parts are sharing literally the same memory, although you do pay for some locks.
If processes, which would be more robust, then the common parts should be in .so/.dll to share the code (common data could be in library-allocated memory, but cleanup is tricky on M$-Windows), and per-instance data is part of the process, which, when a window (tab, too, I suppose, but I don't use them) is closed, would free the memory. Reducing the amount of common storage to simplify its management and having each instance's data in its own space would actually help in Firefox' case, since they currently don't do that very well.
Re:As a Developer the Question I Have Is ... (Score:5, 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.
Re:As a Developer the Question I Have Is ... (Score:4, 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 [slashdot.org].
Re:As a Developer the Question I Have Is ... (Score:3, Informative)
-Operating Systems (C, covered things like memory allocation, caching policies)
This is the class that should have covered multiprogramming issues.
Re:As a Developer the Question I Have Is ... (Score:4, Informative)
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.
Re:As a Developer the Question I Have Is ... (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.
Re:As a Developer the Question I Have Is ... (Score:5, Informative)
Re:Relief (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.
Re:As a Developer the Question I Have Is ... (Score:3, Informative)