[webkit-dev] SharedScript/Worker and multiprocess browsers

[Darin Fisher]

On Mon, Nov 30, 2009 at 6:34 PM, Charles Reis <creis at chromium.org> wrote:

>
>
> 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
>


+1

Oliver, please re-review the use cases in the document.  You'll see that
they are primarily concerned with apps that spawn a window from an existing
window.  I believe it is desirable to support allowing spawned windows to
out-live the original window, which is why a hidden iframe doesn't work.

The unit-of-related-browsing-contexts scoping seems plenty useful to me.  I
don't think it is necessary for SharedScript to solve all of the use cases
of SharedWorker.  (I think the names of these things are confusing matters.)

Finally, the scoping being promoting here for SharedScript matches the
scoping Chrome implements for window.open(name...) / window.name.  That is
similarly restricted to a WebKit process because we do not want to support
synchronous scripting across processes.

Regards,
-Darin



>
>
>> 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
>>
>>
>
> _______________________________________________
> 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/5611ed31/attachment.html>