Define Agent (and Agent Cluster) more concretely

[annevk]

As @allenwb wrote in #882 (comment) it'd be good to formally define agent as holding:

• A set of Realms. The realms in the set are private to the Agent and may not be accessible to any other agent.
• A heap of SharedArrayBuffer objects that whose access may be shared with other Agents
• A set of well-known symbol values
• A GlobalSymbolRegistry

It would also be good to formalize how to get from a Realm to its corresponding Agent (e.g., a language construct a host could reuse).

It would also be good to have the same for agent clusters. I.e., how to get to the cluster from an object (possibly via the realm or agent), and what the cluster consists of (a set of agents).

This is especially useful for hosts that enable communication between agent clusters (i.e., HTML).

(This is effectively what #882 morphed into, but restated for clarity and brevity.)

[syg]

I agree, it'd be good to have more language about this.

[domenic]

In https://freenode.logbot.info/whatwg/20190222#c2016315 @annevk and I discovered that it's probably not a good idea to have an agent hold a set of Realms. At least, it should not be done as an ES-spec-style List; it would need to be a weak set. This is because there are scenarios (e.g. removing an iframe or closing a window.open()ed window) where a realm/global could be GCed, even while the agent is still alive. But if we have a strong reference from the agent to the realm/global, then that is prevented.

Instead, it's probably better to have a realm -> agent pointer. That appears to be what the spec actually needs, e.g. to define "surrounding agent".

Of course, one could hand-wave and say that these spec-strong-references are not observable, and so implementations could collect the realm/global anyway. But at least in the web spec world, we try to write specs to have a reasonably-implementable structure, and not lean too heavily on sufficiently-smart human spec -> implementation compilers.

[erights]

I like the "only realm -> agent pointer" idea better than the weak set idea, if it works. If the spec does need to navigate from an agent to the realms within it, then yes, we should somehow make clear that the agent is not retaining the realms, i.e., that the realms are subject to gc even if the agent is still reachable.

Once we have WeakRefs, then the issue of whether such spec language distinctions creates observable differences is subtle and debatable. Much better to write the spec so that we need not make such subtle arguments to justify collecting an unreferenced realm.

[syg]

Outcome of editor call: work backwards from what HTML wants and needs.

[annevk]

One thing that would be nice to include here is whether the global will expose the SharedArrayBuffer constructor or not. (The functionality should be there either way, but the constructor is problematic for web compatibility reasons.)

HTML currently has

Let status be ! global.[[Delete]]("SharedArrayBuffer").

which is both ungainly and gives the impression hosts should be in control of all of these.

[annevk]

As discussed in #3058 it doesn't solve this issue entirely.