[webkit-dev] SharedScript/Worker and multiprocess browsers

[Jeremy Orlow]

On Mon, Nov 30, 2009 at 6:31 PM, Oliver Hunt <oliver at apple.com> wrote:
>
>  Has anyone really sat down and compared the use cases given in the spec
>> to the behaviour of users? eg. to see if the model you're talking about
>> would actually provide any real benefit in real world usage
>>
>
> The spec was co-written by real world users (gmail engineers).
>
>
> Engineers are not everyday users -- I am not referring to developers (i've
> been fairly careful in this discussion to not conflate developers with end
> users), I am referring to actual end users and their interaction with the
> browser.  If a SharedScript is meant to indicate that a new process
> shouldn't been spawned it seems reasonable to require SharedScripts actually
> be shared.
>

The end user benefit is lower latency and resource usage.  If you click the
link in gmail to tear off a chat window or compose email window there's
(very) user noticeable latency.  Some of this we can continue to improve
with browsers, but it's not easy and it will definitely be a while before an
app like gmail can be loaded in 100ish ms (so it's not perceivable).  And
some (resource sharing) is nearly impossible without help from the app.


On Mon, Nov 30, 2009 at 6:34 PM, Charles Reis <creis at chromium.org> wrote:
>
>  The usage of SharedScript is a strong hint to the browser that future
>> tabs for that origin should be opened in the same process.  With such a
>> heuristic, you only run into trouble when a particular origin doesn't
>> immediately use the SharedScript and a user opens up another tab in the mean
>> time.  This could be mitigated by the browser saving which origins use
>> SharedScript somewhere.
>>
>
> [from the right email address]
>
> Just my two cents, but I don't think the browser's process model should
> change based on a web site's use of SharedScript.  This would end up causing
> all of the instances of a given web site to share a process, which can have
> bad implications for responsiveness.  (Basically, it eliminates most of the
> benefits of having a multi-process browser if the user visits a lot of pages
> from the same site.)
>
> I haven't been following the SharedScript discussion closely enough, but I
> was under the impression that it was mainly targeted at pages opened
> directly from existing pages.  If the user creates separate windows and
> navigates them to the same site independently, I would argue that those
> should not share the same SharedScript.
>

The main purpose of SharedScript is to make web apps more single threaded
(and thus able to share more state).  Besides the whole site crashing when
one tab of it crashes, I don't really see any problem with having the whole
app in the same process....that's essentially what's being asked of us.

If we're only targeting opening new windows via script, then there's really
no reason to do SharedScript since the windows can already access each
other.  You can even do clever things so that children of children still can
communicate even if one of the middle nodes gets closed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/02fc3811/attachment.html>