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

[Adam Barth]

The OpenGL approach to this problem is to have two layers with the
same API.  (Sorry my diagrams aren't as awesome as Maciej's.)

Application
--- WebKit2 API ---
Multiproc client implementation
=== Process Boundary ===
Multiproc server implementation
--- WebKit2 API ---
Singleproc implementation
WebCore, etc

Notice that the WebKit2 API appears twice in this diagram.  By
layering WebKit2 over itself, you allow for easy single-process
embeddings:

Application
--- WebKit2 API ---
Singleproc implementation
WebCore, etc

This design as worked well for OpenGL over a long period of time,
including several revolutions in underlying technology (system of
components, daughter board GPUs, integrated with the CPUs).

Another benefit of this design is it separates the multiprocessing
concerns from the concerns of implementing the API because the
multiproc layer is purely concerned with proxying the API over a
process boundary.

Adam


On Fri, Apr 9, 2010 at 8:00 AM, Evan Martin <evan at chromium.org> wrote:
> 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.)
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>