Slashdot Log In
New Firefox Project Could Mean Multi-Processor Support
Posted by
timothy
on Thu May 07, 2009 04:06 PM
from the but-should-a-browser-need-multi-processors dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
As a Developer the Question I Have Is ... (Score:5, Insightful)
As chipmakers demo 64 or 128 [gizmodo.com] core chips, why aren't we coding and being trained in Erlang [wikipedia.org]? 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.
Re:As a Developer the Question I Have Is ... (Score:5, Funny)
Parent
Re: (Score:3, Interesting)
I wish Opera will catch up soon to this aswell. Its a great browser, but when it does crash on some page whole browser goes down. They have to soon, seeing all other major browsers have implemented it.
Re:As a Developer the Question I Have Is ... (Score:5, 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.
Parent
Re: (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: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.
Parent
Re:As a Developer the Question I Have Is ... (Score:5, 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.
Parent
Re: (Score:3)
It is not hard to to get right, when you leave side-effects out of the language. Because of the determinism and independence from other parts of the program, you can easily split the code processing, and even cache results wherever it helps. Automatically. (Of course you can still manually control it.)
Re: (Score:3, Insightful)
In "why isn't everybody doing this?" the "this" refers to not doing multi-threaded programming; it means forking a process and talking over a pipe (or some other much-high-level-than-shared-memory IPC), which is actually pretty easy to do and hard to fuck up.
The catch is, it tends to be harder to think up ways to split your program into multiple processes that can really be useful with such relatively limited IPC (relatively limited, as
A funny answer, but it's also the serious one (Score:3, Insightful)
Because it's hard?
Re:As a Developer the Question I Have Is ... (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.
Parent
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].
Parent
Re:As a Developer the Question I Have Is ... (Score:5, Funny)
)
Sorry, I can't sleep if I know there is a bracket left open.
Parent
Re:As a Developer the Question I Have Is ... (Score:4, Funny)
Parent
Re: (Score:3, Funny)
His Lisp had a compile error.
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.
Parent
Re: (Score:3, Insightful)
For the most part we are not doing it because it is a totally useless activity. The vast majority of programs out there gets along fine with a single thread (or just a few threads for specific purposes). Adding more threads will not make them faster or better in any appreciable way.
And thread creation / communication / synchronisation also has an overhead, and that overhead might very well add up to slower overal programs. Besides, if you are working and your computer just seems to stop for a second... That
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.
Parent
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.
Parent
Re:As a Developer the Question I Have Is ... (Score:4, 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.
Parent
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.
Parent
Re:As a Developer the Question I Have Is ... (Score:5, Informative)
Parent
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
Really? Not that I noticed. I was tought Pascal, Ada, 68000 machine code, and they let us play with a little C off the record. Oh and Cobol, of course. No threading at all. That was around 1990.
Having talked to programmers who qualified more recently, it hasn't got any better except they now get to learn C 'officially'. It takes around 6-9 months for a new programmer to pick up how things are done in the real world after being through the education system.
Re: (Score:3, Interesting)
I'm pretty sure that was plain textbook stuff (from the first chapter of Tanenbaum's Operating Systems), as you would fail the grade if you didn't get it to work.
responsiveness (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.
Re: (Score:3, Funny)
sive--including the STOP button or the button to CLO...
SE the mi...
sbehaving tab. The UI should never freeze for any reason.
Hear! Hear! I don't recall any problems of this nature back on version 2.x of Firefox. And why does my bank's website think I'm running from a different computer every time there's a minor update to Firefox?
Re:responsiveness (Score:5, Insightful)
Parent
Re:responsiveness (Score:4, Insightful)
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.
Parent
Re: (Score:3, Interesting)
If I look at a page like The Drudge Report, I can ctrl-click on 10 links, creating 10 background tabs. Then, I click on the first article tab, read a bit, close the tab. That shows me the 2nd article. Close it, and I get the 3rd. etc.
This way, I don't have to wait more than 50ms to go from article to article. They are already loaded in the background for me.
Very handy!
Doesn't everyone do this?
Finally! (Score:5, Interesting)
Otherwise, I'd probably switch to google chrome eventually, which doesn't have the add-on support I enjoy from firefox.
Relief (Score:3, Insightful)
Re: (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 th
So here's the $10,000 question... (Score:3, Insightful)
I guess it can be useful in... (Score:4, 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".
Catchy Name (Score:5, Funny)
Re:Catchy Name (Score:5, 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...
Parent
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
Following the link on that page Kitsune [wikipedia.org] the Japanese word for fox, particularly in folklore. "The more tails a kitsune hasâ"they may have as many as nineâ"the older, wiser, and more powerful it is"
The problem is not threads vs processes... (Score:4, Insightful)
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?
Re:The problem is not threads vs processes... (Score:5, 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.
Parent
Re:The problem is not threads vs processes... (Score:4, Insightful)
Parent
the real question is... (Score:4, 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.
Interest dynamic between Firefox and Chrome: (Score:4, Insightful)
I kind of like single-processor apps. (Score:5, Insightful)
Re:I kind of like single-processor apps. (Score:5, Insightful)
If a process using 100% of your cpu "cripples" your machine your OS is broken,
Parent
Re:How about threads? (Score:4, Interesting)
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.
Parent
Re: (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: (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 manag
Re:How about threads? (Score:4, 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?)
Parent