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 <[email protected]> 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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
