Re: [webkit-dev] multi-process always [Re: Announcing WebKit2]
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 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 wrote: > > On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson > 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@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] multi-process always [Re: Announcing WebKit2]
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 wrote: > On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson 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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] multi-process always [Re: Announcing WebKit2]
On Thu, Apr 8, 2010 at 4:01 PM, Anders Carlsson 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
