On Fri, Dec 18, 2009 at 9:47 AM, Charles Reis <[email protected]> wrote: > 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.)
Right, we'd have to make sure that every IPC message could "fail" similar to how network requests can fail. That could lead to a lot of complexity. On Fri, Dec 18, 2009 at 10:37 AM, Peter Kasting <[email protected]> wrote: > This was the proposed solution when we came up with this idea a while back. [...] > In the earliest days, we had hoped that the browser side of Chrome would be > so lightweight that it could basically be made completely crash-free. It > has turned out that that was wildly optimistic. I'm not surprised this idea has come up before. If I have some time to play with this kind of thing, I might try to put together a prototype. I'm certainly willing to believe it's more complex that it appears at first. On Fri, Dec 18, 2009 at 10:44 AM, Scott Hess <[email protected]> wrote: > 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? That's an interesting problem that we'd have to deal with. > 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!). Yeah, this is a good approach too. I wonder if we could do this with the network stack since it mostly talks to the renderer anyway. Adam -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
