[webkit-dev] SharedScript/Worker and multiprocess browsers
creis at chromium.org
Mon Nov 30 18:34:38 PST 2009
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
>> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev