[webkit-dev] SharedScript/Worker and multiprocess browsers

[Jeremy Orlow]

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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/9b6b4175/attachment.html>