[whatwg] Global Script proposal.

[Mike Wilson]

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