- From: Mike Wilson <mikewse@hotmail.com>
- Date: Mon, 31 Aug 2009 17:26:53 +0200
Ian Hickson wrote: > > Given that all frames in a > browsing context have to be on the same thread, > regardless of domain, then unless we put all the > browsing contexts on the same thread, we can't > guarantee that all frames from the same domain > across all browsing contexts will be on the same > thread. Right, the GlobalScript proposal would cause an additional vector that enlarges the sets of "related similar-origin browsing contexts", ie making more browsing contexts share event loop. But there are already a number of relationships that cause this, so can we really say that having one more is not possible? As an application developer I wouldn't have any problem with knowing up-front that my application would "share thread" with the other "instances" (pages) of my application if I use the GlobalScipt feature. (And has been mentioned, it wouldn't be a forced requirement.) @Dmitry: as an implementor, do you find problems with having a loaded page change event loop and thread, or is that just about swapping around data structures? What I'm thinking about is that if swapping is possible, then every page can start on its own thread, and then only swap over to the shared thread for that "unit of related similar-origin browsing contexts" if referencing a GlobalScript. (If swapping is not possible, then every page would have to try to join the thread for its origin at load time, to be prepared for GlobalScript sharing, and that would probably pull together more browsing contexts than desired into shared threds...) > [...] > Granted, programmers today don't want to use > threads -- but, well, tough. > All indications are that that's what the > programming model of the next few decades is > going to be; now is the time to move that way. > We shouldn't be adding features that actually > move us back to the single-threaded world. FWIW, I don't see the GlobalScript proposal as something that wants to avoid multi-threading. Though, with JavaScript's "shared nothing" approach between threads, single-threading is a side-effect of having "live" access (no intermediate serializing/cloning) to shared data. If there was multi-threaded access to data (you could say there already is with cookies and the storage mutex) I'm sure the GlobalScript proposal could be tailored to take advantage of that. Best regards Mike
Received on Monday, 31 August 2009 08:26:53 UTC