Comment 105 for bug 2697

I'm not sure this bug is the appropriate place to put "Bug 457950". I wasn't so concerned with a plugin crashing the browser (though that is a concern), I was more concerned that a plugin (Adobe flash) running in one window, wants to use all of the CPU. That's fine. I have 4. But in a separate window, I am still "automatically" limited to only running on the 1 used processor. I have 3 unused processors that can be used to browse or whatever -- but because the one window that's running flash is using such a high level of CPU, Adobe Flash keeps emitting error messages that a "script" (the flash script, I guess) is hogging the CPU (it is -- it's playing a hi-def movie that's barely being kept in sync -- probably a poor implementation by nbc.com), but I want to allow it to have its own CPU -- and keep browsing in *other* cpu's.

When a plugin is using 80% of 1 cpu (as in my bug), the adobe flash player detects the high Cpu usage and high latency and brings up warning messages. There isn't a CPU crisis -- it's just 1 cpu that's busy. Why can't those plugins get a separate thread ? Maybe __at least__ allow other WINDOWS to use other CPU's -- That's the bug. When firefox is already using 100% of one cpu, it still blocks another instance of firefox from starting to run on another cpu. It forces all windows to the same cpu.

Why not make access to the profile protected with 'locks' and/or shared memory to hold a common state?

This is the biggest value of Googles new browser over Firefox -- you can bet MS will have IE be multithreaded, but I saw Google's browser release being a direct competition to Firefox because FF is limited to 1 thread. They are both open source -- they can both converge to a similar feature set -- but Google's browser isn't based on mono-threaded code so it can expand. FF is stuck.
I could easily upgrade my system to eight cores -- but what would be the point? I can't even make due with 4 cores, yet I am very often CPU bound in 1 core due to Firefox's stuck implementation.

In fact -- I don't require that the browser stay up if a plugin crashes -- that's far less common of an occurrence for me. What is common is that every day, every FF window and tab are run in a small quarter-sized compartment in my computer because FF is so poorly written.

Why was it written as single threaded in the first place? Seems like poor design from the start. By default, code should be re-entrant and only non reentrant by special exception or necessity. This has been a problem since the beginning, yet it keeps getting put off to some vague nebulous future.

What's the problem -- as even IE will supposedly run on separate cores (not sure if that was referring to future or now)?

But if bug 457950 doesn't require the browser to "not crash" when a plug-in crashes, is it really the same bug as this one?