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 <abe...@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 <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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev