How would you know which renderer was the one which engineered the crash to cause you to loose some sort of interesting state about that renderer so that it can attack?
It might be better to think on performant ways to carve complex bits out of the browser process. Already many of our background threads could probably live in a distinct process and send data back and forth via IPC without too much performance loss. This would have the nice side-effect of not being able to pass pointers between threads (not only would we be protected from crashes, we'd crash less often in the first place!). -scott On Fri, Dec 18, 2009 at 9:47 AM, Charles Reis <[email protected]> wrote: > I'd love to see this happen, but I wouldn't be surprised if there's lots of > state that's hard to restore. For example, how would the new browser > process know which renderers are waiting for responses to some request, in > order to return failures to them? I suppose we could just send a > "re-parented" message to all of them, so that they know not to expect > responses to earlier requests. > You've covered at least one of the tricky parts, which is knowing which > renderer processes need to be "re-parented." (There could be multiple > browser profiles running, so it won't be all of the Chromium renderer > processes.) If we had any other need for a second trusted browser process, > such as running some browser component with a little more isolation, then we > wouldn't need a dedicated watchdog process. > Either way, we'd be replicating state between multiple processes, which > would be tricky but would let us survive failures in either process. Might > add some IPC overhead to actions like creating a new tab, if we want to be > sure the replicated state is kept consistent. > Any other examples of browser state that would be tough to restore? How bad > would this be for open network connections? (I imagine it's like the > network cutting out for a bit.) > Charlie > > 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
