[webkit-dev] SharedScript/Worker and multiprocess browsers

[Darin Fisher]

On Mon, Nov 30, 2009 at 4:07 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote:
>
> I don't think it's correct to say that SharedWorkers are not useful and "we
> need a SharedScript instead". They are different things and can address
> different use cases. For example, SharedWorker is great to make sure there
> is only one 'app instance' running - exactly because it is shared
> inter-process, it can be used as a "inter-process synchronization primitive"
> to control how many app instances are opened. SharedScript is a container
> for data and code shared between pages that comprise a "web application" and
> normally run in the same process. As in native apps, whether or not multiple
> instances of the app can run at the same time depends on the author of the
> app, and can be done either way.
>
> Multi-process browsers are bringing more complexity (and benefits). Not all
> technical issues<http://www.chromium.org/developers/design-documents/process-models>are completely resolved in Chrome's implementation, and we might need (or
> not) some mechanism of saying that a bunch of pages form "an application"
> and should share a process. Right now, it's unclear if such mechanism even
> needed though.
>
> I agreed with you to remove the implementation details from the doc because
> indeed they do not belong there. Not that they are not existing. For
> example, the fact that in Chrome SharedWorkers are indeed inter-process
> theoretically could be different. WebWorkers spec does not specify where and
> how to look for instances of SharedWorkers, although it implies some useful
> degree of sharing. The fact that in Chrome they are shared across all
> processes is a detail of Chrome implementation.
>
>
> The Worker implementation behaviour is not really relevant to this
> conversation.  The issue is whether a browser implements a spec in a correct
> manner, that's why implementation is not described.  A worker for instance
> may be per thread, per process, or may not even represent a separate machine
> thread and could be implemented by in software just running each task in
> sequence (assuming a sufficiently careful implementation, etc, etc).
>
> The issue we're discussing however was what Darin bought up -- should a
> multiprocess browser be allowed to have multiple distinct instances of the
> same Global/SharedScript?  the answer is clearly no (and that concept has
> been removed from the spec);
>


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.




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

Cheers,
-Darin



>
> The resultant implication is that a "Shared" or "Global" script would have
> not need to be shared at all and each page could have it's own copy --
> effectively degenerating to a glorified iframe.
>
> I would consider it to be a warning sign of potential badness in a spec if
> behaviour was being defined by perceived difficulty in implementing a
> feature, rather than on the desired end user behaviour.  In general I feel a
> spec should always favour complexity of implementation over complexity in
> use, after all if a feature is hard to implement it still only needs to be
> implemented a relatively small number of times (basically once per
> browser/engine) pushing the complexity on to end developers however then
> means thousands (millions?) of developers have to implement the same code
> and deal with the same complexity over and over again.  Obviously if there's
> an option to avoid any complexity that would be best, but i suspect that's
> unlikely to exist :-D
>
> --Oliver
>
>
> Dmitry
>
> On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>
>> > Just a note:
>> >
>> > In Chrome, a SharedWorker is reachable from any WebKit process, whereas
>> a SharedScript would only be reachable within a WebKit process.  This is an
>> interesting distinction, and I can imagine some use cases for SharedWorker
>> that SharedScript could not address.  (This distinction arises because we
>> did not want to build a script proxy between WebKit processes as that would
>> be quite costly.)
>> >
>> > For example, suppose you wanted to have only one instance of a web app
>> responsible for manipulating a database or communicating with a server.
>>  There's no guarantee that multiple instances of a web app would all run in
>> the same WebKit process.
>>
>> Actually, I objected to that distinction, and it has been removed from the
>> specification.
>>
>> You can find the discussion here:
>> https://bugs.webkit.org/show_bug.cgi?id=31317.
>>
>> And the specification here:
>> http://docs.google.com/View?id=dxv3cth_4gvggh3gh.
>>
>> I'm concerned that a lot of Chrome engineers are speaking for "Google",
>> but they don't really have their stories straight. First, a group of Chrome
>> engineers said that "Google" needed SharedWorker, so it was implemented in
>> WebKit. Now, a group of Chrome engineers says "Google" can't use
>> SharedWorker, and needs SharedScript instead. So, we're gearing up to
>> implement that. Meanwhile, not all Chrome engineers agree about what
>> SharedWorker is or why it is that way, and we can reasonably assume that the
>> actual Google engineers who have asked for these technologies disagree even
>> more.
>>
>> It's OK to disagree and hash out ideas. But it's a little weird to try to
>> dictate the direction of WebKit in the name of "Google" and "several major
>> apps with millions of users", when that standard seems to blow whichever way
>> the wind goes.
>>
>> Geoff
>
>
> _______________________________________________
> 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/ef329ed2/attachment.html>