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

[Darin Fisher]

This is how we are designing the Pepper API [1] by the way.  It is designed
to be layered in order to support an optional, out-of-process
implementation.

I've always been interested in a similar model for WebKit.

-Darin

[1] https://wiki.mozilla.org/Plugins:PlatformIndependentNPAPI


On Fri, Apr 9, 2010 at 8:13 AM, Adam Barth <abarth at webkit.org> wrote:

> 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
> >
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100409/57d03830/attachment.html>