I suspect that you could eventual create a minimal watchdog (uber browser?) process, controlling a fleet of (more than one) browser process, each browser process controlling one or more renderers (whew). The good news is that such an architecture would probably get around some of CPU's sandbox concerns, but there would be a lot of complexity and state-shifting between the uber browser and browser process.
...we might get more robust... but our already high process-count would probably roughly double... and that would likely carry with it increased memory usage :-(.... and decreased customer satisfaction. [resending from chromium.org account] I think it was a GIANT step forward when Chromium survived renderer crashes. I'm not all that clear that another level of process-division would increase robustness, and more importantly, increase customer satisfaction. Eventually we head toward interesting limits. I recall hearing that ECC memory was found to be less reliable than parity, because the increased logic complexity caused more failures that the ECC could salvage. The net-net was less reliable hardware with ECC!?! (Maybe this has changed... as it may have been caused by increased board-count... but I'm not sure). It would be a shame if Chromium moved towards "more robustness" but ran slower because of endless memory footprint growth. I've already pondered if we've accidentally crossed this line for users with MANY tabs. It would be good to also compare our stability metrics to a "control" process that we *think* is virtually "crash proof." I've chatted with Huanr about this, and I think we should be sure to identify what the base-level of noise (crash rate?) is for a system running our our user's computers. No matter what we do, users will "pull the plug" at times and induce a "less than clean shutdown." There will also be random corruption, and OS based corruption, which we can (seemingly) not avoid. It would be good to quantify this baseline. Jim On Sun, Dec 20, 2009 at 10:20 PM, Darin Fisher <[email protected]> wrote: > It's already been said, but this was something we considered in the very > beginning. > > There's a lot of state in the browser buried in classes that are not > designed to be restarted. We have had enough trouble resetting state in the > browser corresponding to a tab that crashed and reloaded. > > One thing that might help is to factor the browser process into two. If we > can carve off a meaningful chunk, perhaps we can also design that chunk to > be restartable. It might help to look at what parts of the browser process > have had the most crash bugs. Maybe anything that doesn't happen on the UI > thread (gross approximation)? > > -Darin > > > On Fri, Dec 18, 2009 at 9:13 AM, Adam Barth <[email protected]> wrote: > >> Currently our multiprocess architecture lets the browser keep going >> when one of its tabs crash, but why can't we keep the tabs going when >> the browser crashes? >> >> At a high level, imagine we had a watchdog process that kept track, >> essentially, of the tab model and the navigation controllers. When >> the browser process crashes, we could use this information to do >> something like session restore, but instead of reloading the tabs from >> the network, we could re-attach to the tab processes that are already >> running. >> >> There's some trickiness revolving around in-flight requests from the >> renderer processes to the browser process (such as synchronous >> XMLHttpRequests), but that seems like a solvable problem. Basically, >> the approach would be to respond to any in-flight requests with >> "failure" messages. >> >> Thoughts? >> >> Adam >> >> -- >> Chromium Developers mailing list: [email protected] >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > > -- > Chromium Developers mailing list: [email protected] > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
