[webkit-dev] SharedScript/Worker and multiprocess browsers
oliver at apple.com
Mon Nov 30 18:31:43 PST 2009
> 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).
Engineers are not everyday users -- I am not referring to developers (i've been fairly careful in this discussion to not conflate developers with end users), I am referring to actual end users and their interaction with the browser. If a SharedScript is meant to indicate that a new process shouldn't been spawned it seems reasonable to require SharedScripts actually be shared.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev