[webkit-dev] GlobalScript in WebKit

[Oliver Hunt]

On Nov 30, 2009, at 4:18 PM, Jeremy Orlow wrote:

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

It would not need to reference a storage mutex in any way -- Global/SharedScript runs inline, it's deliberately intended to not be a separate thread, and therefore from the PoV of the spec there is no concurrency.  Ensuring correct semantics is simply an implementation detail that is completely distinct from the main spec.

--Oliver

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