Chrome's Process Model Explained(blog.marcchung.com)
blog.marcchung.com
Chrome's Process Model Explained
http://blog.marcchung.com/2008/09/05/chromes-process-model-explained.html
2 comments
It shouldn't fragment WebKit development much at all. WebKit2 is just an API layer on top of WebCore, much like the Qt and GTK WebKit API layers. Most of the work is done by WebCore, which is shared by all the API layers.
> WebKit2 is just an API layer on top of WebCore, much like the Qt and GTK WebKit API layers.
WebKit2 is a very different API than WebKit1, though. For one thing, it is non-blocking, and that necessarily means a lot of changes underneath.
Chrome was built around WebKit1, and it may be clunky to layer it on WebKit2, as it seems unlikely that Google will rewrite/remove Chrome's special multiprocess code and use WebKit2 instead.
So I definitely see some tension between Chrome and Safari here. WebKit2 is multiprocessing for WebKit 'done right', while Chrome's approach was, I suspect, in part done in order to get results quickly (and indeed it got to market far, far before WebKit2).
The duplication of multiprocess code for WebKit is already itself fragmentation in WebKit, which is not surprising given the development model there. But, I expect WebKit to continue to be an excellent project nonetheless.
WebKit2 is a very different API than WebKit1, though. For one thing, it is non-blocking, and that necessarily means a lot of changes underneath.
Chrome was built around WebKit1, and it may be clunky to layer it on WebKit2, as it seems unlikely that Google will rewrite/remove Chrome's special multiprocess code and use WebKit2 instead.
So I definitely see some tension between Chrome and Safari here. WebKit2 is multiprocessing for WebKit 'done right', while Chrome's approach was, I suspect, in part done in order to get results quickly (and indeed it got to market far, far before WebKit2).
The duplication of multiprocess code for WebKit is already itself fragmentation in WebKit, which is not surprising given the development model there. But, I expect WebKit to continue to be an excellent project nonetheless.
As one of the people who has worked on designing and implementing those changes, I can tell you that we did not need to change much in WebCore. And what we did do will probably be useful for Chrome's different multiprocess mechanism.
Incidentally, I would not say there is anything technically wrong or hacky about Chrome's process architecture. The reason we started anew is that it's not very reusable if you don't buy into the whole Chromium stack. Google chose to make multiprocess an app feature, we made it a framework feature. Reusing Chrome's code for a different app or another platform port would require inserting an API boundary where there was never meant to be one.
We did talk to the Google folks about whether they would want to integrate their multiprocess approach into WebKit itself, but that didn't really meet their needs or plans.
I do hope we can converge and share more over time.
Incidentally, I would not say there is anything technically wrong or hacky about Chrome's process architecture. The reason we started anew is that it's not very reusable if you don't buy into the whole Chromium stack. Google chose to make multiprocess an app feature, we made it a framework feature. Reusing Chrome's code for a different app or another platform port would require inserting an API boundary where there was never meant to be one.
We did talk to the Google folks about whether they would want to integrate their multiprocess approach into WebKit itself, but that didn't really meet their needs or plans.
I do hope we can converge and share more over time.
Thanks for the additional info.
It does seem like this is mainly awkward for Chrome. But probably not a big deal.
It does seem like this is mainly awkward for Chrome. But probably not a big deal.
These design documents have some informative diagrams if you're interested in this topic:
http://trac.webkit.org/wiki/WebKit2 http://dev.chromium.org/developers/design-documents/multi-pr...
http://trac.webkit.org/wiki/WebKit2 http://dev.chromium.org/developers/design-documents/multi-pr...
Much of the code is shared with non-multiprocess ports, and many of the leading WebKit ports have been building a WebKit2 port.
It may even lead to more uniformity, if we can share at least some of the approach to multiprocess with Chromium.
It may even lead to more uniformity, if we can share at least some of the approach to multiprocess with Chromium.
[2008]
I'm really curious if webkit2 is going to be widely adopted, and if so, if and how it'll fragment webkit development.