[webkit-dev] WebKit2 SharedSecondaryProcess model

[Sam Weinig]

Hi,

Sorry for the tardy reply. We currently have no plan to support that model,
but it will be something we can keep in mind as we progress.  I would like
us to concentrate on getting the simple two-process case
(SharedSecondaryProcessModel) working well, before we get more adventurous.

-Sam

On Fri, Sep 3, 2010 at 6:11 AM, 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.
> 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/20100903/9b2e8ebf/attachment.html>