Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define Agent (and Agent Cluster) more concretely #1357

Open
annevk opened this issue Nov 26, 2018 · 5 comments
Open

Define Agent (and Agent Cluster) more concretely #1357

annevk opened this issue Nov 26, 2018 · 5 comments

Comments

@annevk
Copy link
Member

@annevk annevk commented Nov 26, 2018

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
Copy link
Contributor

@syg syg commented Nov 28, 2018

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

@domenic
Copy link
Member

@domenic domenic commented Feb 22, 2019

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
Copy link

@erights erights commented Feb 22, 2019

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
Copy link
Contributor

@syg syg commented Feb 19, 2020

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

@annevk
Copy link
Member Author

@annevk annevk commented Apr 12, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants