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 <k...@inf.u-szeged.hu
<mailto:k...@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@lists.webkit.org <mailto: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
