[webkit-dev] GlobalScript in WebKit

[Jeremy Orlow]

Does anyone have a link to the spec?

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

I don't agree that it's clearly no and I didn't have any clue that it had
been removed from the spec.  If multiple processes/event-loops would share
the same SharedScript instance then we're either not going to be able to
maintain run to completion semantics or its going to need to use the storage
mutex (which would probably need to be renamed).  That would
be unfortunate to put it very...VERY lightly.


> 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.
>
> 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/b9553782/attachment.html>