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."
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.
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.
Relief (Score:3, Insightful)
So here's the $10,000 question... (Score:3, Insightful)
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.
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: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.
Interest dynamic between Firefox and Chrome: (Score:4, Insightful)
I kind of like single-processor apps. (Score:5, Insightful)
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.
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.
Re:responsiveness (Score:5, Insightful)
Makes Firefox/browser platform of the future (Score:2, Insightful)
Making Firefox act more like a real operating system, each "application" runs in its own process is another step in that direction. It means that my gmail browser window won't crash if I surf to some buggy website. And it means that I can run a lot of browser based application faster and more stably.
This is the next logical step for people to start using Google word processor running in firefox instead of Word or OpenOffice. Once there's a stable browser based platform for browser applications to run in, a whole world of possibilities begins to opens up.
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.
Re:The problem is not threads vs processes... (Score:4, 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,
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.
Re:The problem is not threads vs processes... (Score:2, Insightful)
What, you mean like ActiveX and code signing? Anything goes, as long as the user knows it's dangerous?
The era of "trust the user to make intelligent decisions" is long gone. I would argue that it never really existed in the first place. Computers are for people who don't want to know how the computer works. They don't want to see Big Scary Dialog Boxes where they have to make the Right Choice or else their system could be compromised.
The onus is on application developers to minimize the frequency of scary choices, and to mitigate the impact of a wrong choice as much as possible.
There will always be malware that wants to install itself, websites that spread misinformed "security" tips, scammers who trick people into making wrong choices. And of course there will always be buggy or exploitable code.
Increased testing is useful. Increased architectural safety is MORE useful.
Re:As a Developer the Question I Have Is ... (Score:2, Insightful)
Any bloke can use a thread and a few locks, or toss in some OpenMP pragmas on a for-loop. But what about: priority inversion, memory barriers, atomic operations, lock-free data structures, concurrency under deadline scheduling, deterministic concurrency, automated task-graph analysis. Not advanced concepts?
Re:As a Developer the Question I Have Is ... (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 opposed to just sharing data structures, I mean). i.e. what is each side of that pipe going to be doing and what will they be talking to each other about? So: it takes more .. uh .. imagination(?), but less skill.
And yeah, more people ought to try it out, because in situations where you can use this technique, it's really neat, and generally not as bug-prone (and that is the real payoff).
Re:Catchy Name (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"
Re:I kind of like single-processor apps. (Score:2, Insightful)
If a process using 100% of your cpu "cripples" your machine your OS is broken
I've had both Win and Lin do that (32- and 64-bit) on various computers. Preemtive multitasking on multiple CPUs should make it impossible yet it still happens. What's worse is that by the time top (or whatever process viewer) gets around to actually showing something--possibly 10 minutes later--the culprit process is done masturbating so you can't tell who it was. Something's just wrong when even a text-mode terminal takes minutes to do anything.
Re:How about threads? (Score:1, Insightful)
What a load of cr*p.
Sure, on any modern system, the overhead of having "multiple copies of the same process" is minimal.
That doesn't change the fact that:
- synchronization between threads or processes is just as difficult either way. A mutex is a mutex, a semaphore a semaphore and so on.
- communication, on the other hand is much easier with threads. And just because you're using threads doesn't somehow forbid you to use "well-defined interfaces". Other things being equal, you might want to save yourself the whole copy stuff to shared memory and back mess. Remember that extra code is an extra source of bugs.
Where process have an advantage, still, is when you're running arbitrary code in one. Plugins for instance. That has the potential to crash the whole thing in a single process, while a *correctly coded* IPC can survive it. Emphasis on correctly coded because otherwise you'll end up with a lockup instead of a crash, not exactly an improvement.
Since we're talking about plugins, I'd favor processes in this specific case.
But that's not to say that processes are inherently superior to threads. They're only so in the mind of people who grew up with Unix, decided that OS architecture reached perfection in the 70s and shut their mind about threads because that was "new" and/or something Windows better at. Pitiful.
As for Erlang, I'm still waiting for an halfway decent app written in it that's used by more than 10 people. And that doesn't include that stupid router we keep hearing about: developers who can't code 6 nines of reliability out of 10 years matured specs running on custom telco-spec hardware don't deserve the title, be it in C, C++, Java or Erlang.
Re:As a Developer the Question I Have Is ... (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's most likely Windows paging your program in or out. No amount of threading will save you from that.
I look forward to those 1024-core chips, but only because I want to see raytraced games. I do not want to see raytraced email, browse raytraced websites, or listen to raytraced mp3's. Those things already work just fine as it is.
Urgh...I don't think users want a process per tab (Score:2, Insightful)
In my experience, the HTML rendering is not the major crash or performance bottleneck issue with Mozilla.
Users want separate processes for all plugins, i.e. a switchable mode in-process or out-of-process mode selectable for each plugin through Mozilla configuration. Let the plugins crash in their own, see ndiswrapper for some ideas on that.
Users want a JavaScript engine that operates in a thread of its own (an extra thread per tab as necessary, when there is JavaScript work to do, think like dynamic thread pooling of JavaScript worker threads, most of the time 1 or 2 threads will handle JS in all your tabs).
Users want all file/disk access to be in a separate thread to the UI. I believe network I/O already is (or is non-blocking at least).
Hey move the entire file configuration/ SQLLite/ management for mozilla to a separate process that doesn't crash (even if the main Mozilla UI does). Users also want that damn stupid Linux/ext4 issue fixed and the horrible performance fixed, yes mozilla is more crazy than linux, and nope as a user it is Mozilla that crashes not the Linux the OS. In order to get application level crash recovery you make all writes to your database journaled through your own logfile. It is only the writes to that journal that need to sync to disk. Yes Eric is right mozilla should be more efficient in reducing the probability that a write to disk needs to extend a file so syncs don't cause an inode flush to stall the fs transaction throughput.
But separate web pages in separate processes, just makes no sense to me. Most of the time requires little CPU as reading/thinking time dominates the moments of Mozilla klunkyness.