[webkit-dev] GlobalScript in WebKit

[Jeremy Orlow]

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

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

What you're suggesting is even one step worse (performance wise) than the
storage mutex: you're suggesting that entire event loops would need to block
on each other.  Of course maybe this is the correct solution to the whole
storage mutex issue....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/1f122a83/attachment.html>