[webkit-dev] WebKit2 SharedSecondaryProcess model

Zaheer zaheer.mot at gmail.com
Sat Sep 4 01:50:18 PDT 2010

On Fri, Sep 3, 2010 at 6:41 PM, Andras Becsi <abecsi at inf.u-szeged.hu> wrote:

> Hi!
> Just to get things clear:
> SecondaryProcessModel:
> Web processes:   {W} {W} {W}    {W} {W}
>                  |   |   |      |   |
> UI processes:   {<t> <t> <t>}  {<t> <t>}
> This should be the model Chrome uses, and the model which saves some memory
> and is parallel should be the
> SharedSecondaryProcessModel:
> Web processes:       {W}          {W}
>                    / | \         / \
> UI processes:   {<t> <t> <t>}  {<t> <t>}
> where <t> means the tabs (or pages) and {<t>} represents a process with one
> tab.
> Balazs, the model you suggested, would look like:
> SharedSecondaryServerProcessModel (maybe):
> Web proces (server):       {W}
>                         ///  \\
> UI processes:   {<t> <t> <t>}  {<t> <t>}
> Right? This means there would be only one WebProcess, which would work as a
> server for UI client processes which connect to it. I see the benefits of
> this in an embedded environment where widgets share one common WebProcess
> and thus this model would use less memory, for example if the WebProcess is
> used by multiple widgets.
Doesnt this model have the drawback of slowing down the response when
servicing multiple clients and even bringing down the system with a faulty
content which is the major plus in other models. Given this, the slightly
extra memory in other models is a good tradeoff IMO (even embedded devices
have large memory these days).

> I see that this model is not really parallel, but saves memory.
> Is there a future plan to support this model too?
> BR:
> Andras
> On 09/01/2010 01:09 PM, Balazs Kelemen wrote:
>> (Sorry for flooding the list but I need to repeat my reply to put it in
>> the right thread.)
>> Seems like I misunderstood the concept. I assumed that the shared
>> process model means that there could be multiply UI process instances
>> that uses the same web process, virtually when the second MiniBrowser is
>> launched it connects to the existing web process. By taking a deeper
>> look into the WebContext and WebProcessProxy classes, I have realized
>> that the shared process model is about using one web process for
>> multiply views (what is cool) and not for multiply processes (what would
>> be more cool from my point of view :) ).
>> What do you think about my idea? Primarily on embedded devices it would
>> be great to use the web engine as a server process because it could save
>> a lot of memory. I think the current design is not too far for
>> supporting that. Mainly we should find a correct way of connecting the
>> new UI process to the existing web process, and the Connection should be
>> per page instead of per process (or we should rework the WebProcess to
>> not be a singleton?).
>> Please provide some feedback on this because it is important for our
>> project to know which way should we go on with WebKit2. Thank you!
>> Balazs Kelemen
>> On 08/30/2010 08:22 PM, Sam Weinig wrote:
>>> Hi Balazs,
>>> Does it not work currently? If not, can you please file bugs on what
>>> is not working. We plan on making the shared process model the default
>>> model for the API, but it will probably have the caveat that it will
>>> not support InjectedBundles.
>>> -Sam
>>> On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen <kb at inf.u-szeged.hu
>>> <mailto:kb at inf.u-szeged.hu>> wrote:
>>>    Hi all!
>>>    I am wondering about do you plan for the mac and win to support the
>>>    shared web process model?
>>>    Actually, I have played around with that for Qt. I have a working,
>>>    proof
>>>    of concept implementation. The visited links and the back-forward list
>>>    features are broken, but apart from that the browsers are working with
>>>    the shared web process. I had to rework common parts of the code for
>>>    achieving that, and I would like to contribute it in small parts. I
>>>    think if we want to support that model in the future than we should
>>>    start to implement it as soon as possible to assure that our
>>>    design fits
>>>    the needs of that.
>>>    Cheers!
>>>    Balazs Kelemen
>>>    _______________________________________________
>>>    webkit-dev mailing list
>>>    webkit-dev at lists.webkit.org <mailto: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
> _______________________________________________
> 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/20100904/e28c1874/attachment.html>

More information about the webkit-dev mailing list