On Mon, Nov 30, 2009 at 4:23 PM, Oliver Hunt <oli...@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 <oli...@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....
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev