And in that case we can hopefully use this for session restore too. -Ben
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
