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 <aba...@chromium.org> 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: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
