[webkit-dev] SharedScript/Worker and multiprocess browsers

[Oliver Hunt]

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.

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

--Oliver



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/f8d846e6/attachment.html>