Join GitHub today
Imperative allocation of agent clusters #4361
This is a follow-up to #4198. The browsing context group concept is added by #4350, but to properly clarify the lifetime of objects, we'll need to imperatively allocate them. In particular, objects might lose their direct connection to a browsing context (e.g., when you remove an
(Alternatively we could perhaps give everything a pointer to the browsing context group, but that doesn't seem like a good architecture, in particular because nothing in ECMAScript really supports that kind of notion.)
This is the setup I have for this thus far:
A browsing context group has associated agent clusters (a map of agent cluster key/agent cluster).
An agent cluster key is an origin or a scheme-and-site. A scheme-and-site is a tuple of a scheme and a domain.
To obtain an agent cluster key, given an origin origin, run these steps:
To obtain a similar-origin window agent, given a browsing context group group and agent cluster key key, run these steps:
To obtain a browsing context agent cluster, given a browsing context group group and agent cluster key key, run these steps:
(This intentionally does not cover workers. They can use a simpler allocation setup that can be sorted as part of #4339.)
referenced this issue
Feb 17, 2019
It's true that the script from one agent X may hold onto an object O from another agent Y but if Y dies, there is no more execution context or stack left for Y. We can't, for example, start evaluating or dispatching events in Y.
At least in WebKit, each document has its own script execution context only when it's associated with a frame (i.e. a browsing context) and when it gets detached from a frame, its script execution context and therefore the agent associated with it is dead.
I'd be curious to know how Gecko is architected here.