[webkit-dev] multi-process always [Re: Announcing WebKit2]

[Evan Martin]

On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson <andersca at apple.com> wrote:
> WebKit2 is designed from the ground up to support a split process model,
> where the web content (JavaScript, HTML, layout, etc) lives in a separate
> process. This model is similar to what Google Chrome offers, with the major
> difference being that we have built the process split model directly into
> the framework, allowing other clients to use it.

One thing I'd discussed with the WebKitGtk folks in the past is
whether/where multi-process WebKit fits into apps.  An app that just
wants a quick HTML component -- say it wants to embed some known
safe/simple HTML content (consider for example the bits of the MS
Windows control panel UI that are done in HTML, or the system help
viewer) doesn't worry a lot about the stability/performance benefits
of multiproc but might care about the memory/developer overhead.
(Developer overhead for the embedder, in the sense that multiproc is
more painful to debug and code for.)

>From the original announcement I could see the above description going
one of two ways:
- WebKit2 could *support* a split process model, by adding all the
callback-like hooks described, while still allowing an embedder to
implement it in a single-process way
- or WebKit2 could define and implement a split process model

The Chromium port vaguely aims at the former, though I think it falls
out more from not wanting to stuff even more Chromium-specific code in
the WebKit tree.  :)  It seems from the graphics Maciej posted that
the latter is what you're doing.  Is that correct?  Do you have any
intent to continue supporting a single process model?

(There's some compromise path between the above two, where you require
the asynchronous interface but allow embedders to just use in a
thread.  We've found this to be a bit finicky to keep working in
Chrome, and while that could be our bad engineering practices, if it's
kept on the table it certainly will require continuing engineering
effort to support.)