[webkit-dev] SharedScript/Worker and multiprocess browsers

[Charles Reis]

On Mon, Nov 30, 2009 at 6:16 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> On Mon, Nov 30, 2009 at 5:58 PM, Oliver Hunt <oliver at apple.com> wrote:
>
>>
>> On Nov 30, 2009, at 5:40 PM, Jeremy Orlow wrote:
>>
>> On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote:
>>
>>>
>>> Sorry, I think you misunderstand.  The way Chrome processes are divided
>>> is an implementation detail, but it is an important one.  I think it is
>>> folly to ignore it when designing web APIs.  We'll likely *never* implement
>>> APIs that involve cross-process, synchronous script evaluation.  We have
>>> some experience with that in supporting plugins, and I can tell you that I
>>> do not favor it: not just because of implementation complexity but also
>>> because of the performance impact it entails.
>>>
>>>
>>> It is wrong to design an API based on architectural decisions of your
>>> existing browser -- you should be making decisions based on what the
>>> developers actually need.  Being hard for the browser to implement is a
>>> secondary concern next to being hard for the end developer to use.
>>>
>>>   The issue being that in regular day to day use such a browser could end
>>>> up producing behaviour inconsistent with behaviour that of browsers that
>>>> actually did provide a single shared context -- in effect all users of
>>>> Global/SharedScript would have to assume that their Global/SharedScript
>>>> context was not in fact shared.
>>>>
>>>
>>> This is true, but I don't think it is a big deal.  Processes are roughly
>>> divided up into browsing units.  You start a new browsing unit by opening a
>>> new tab and navigating it.  By doing so, you are creating a separate world
>>> that cannot see other worlds.  SharedWorkers (as well as cookies and other
>>> storage mechanisms) provide a bridge between these worlds, but window.open
>>> and SharedScripts do not (b/c of the script connection they imply).
>>>
>>>
>>>
>>> I have a (simple) question: If Global/SharedScript is not guaranteed to
>>> be either Global or Shared, what is it trying to accomplish?  It's not
>>> possible for any developer to use them for shared state as they can't
>>> guarantee that a normal user, doing normal things, is not going to end up
>>> with distinct instances of this "shared" state.
>>>
>>
>> Please look at the use cases in the spec.  They're pretty much all an
>> optimization to cut down on resource utilization and load times by sharing
>> more state.
>>
>>  As a side note, I would expect that many SharedScript users would also
>> use SharedWorkers for a lot of the non-UI logic including storage and
>> network.
>>
>> Also note that the possibility of having multiple SharedScript instances
>> within one browser is pretty much the same as the possibility of the user
>> having multiple browsers open on the same computer.
>>
>> The point i was getting at is that unlike the typical way to get this
>> situation (running multiple browsers) is not a common end user behaviour,
>> but Chrome's model makes it very easy -- as far as I am aware if I open two
>> windows independently and navigate both to example.com i will end up with
>> two processes, thus ending up with two instances of the same SharedScript.
>>
>> I actually just did a quick test, and I am unsure how I can actually open
>> two windows in such a way that Chrome would end up using a single
>> SharedScript instance -- both new window and new tab result in separate
>> processes, the only logical case that would allow multiple windows to end up
>> sharing an instance (and thus gaining any benefit at all from this
>> feature) would be by opening a window from an original source page, in which
>> case an invisible iframe could trivially be passed around, and has all of
>> the advantages of SharedScript, none of the disadvantages, and works in all
>> existing browsers.
>>
>
> 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.

Charlie


> 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).
>
> _______________________________________________
> 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/20091130/3c4c021f/attachment.html>