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

Making worker/worklet agent allocation imperative #5210

Closed
domenic opened this issue Jan 14, 2020 · 5 comments · Fixed by #5411
Closed

Making worker/worklet agent allocation imperative #5210

domenic opened this issue Jan 14, 2020 · 5 comments · Fixed by #5411
Labels
clarification Standard could be clearer topic: agent The interaction with JavaScript's agent and agent cluster concepts

Comments

@domenic
Copy link
Member

domenic commented Jan 14, 2020

In working on origin isolation I am finding it a bit annoying that only window agent creation is imperative. Let's figure out what it would look like to convert everything else.

Here's my first attempt:

  • End goal:
    • all realm creation ("create a new JavaScript realm" calls) include an agent pointer, either created on the spot or looked up from elsewhere.
    • We delete the "can share memory with" equivalence relation and associated implicit definitions. (Maybe we keep them as informative?)
  • Shared worker agents: creates a new agent and agent cluster on the spot. Does not need to store it in any map; all access can go through the shared worker.
  • Service worker agents: same as shared worker agents.
  • Worklet agent: grabs the owner document's agent cluster. Creates a new agent inside the agent cluster.
  • Dedicated worker agent: grabs the "relevant owner to add"'s agent cluster. Creates a new agent inside the agent cluster.

Hmm, but how exactly do we grab the owner's agent cluster? We can get from document/WorkerGlobalScope to realm to agent, but not from agent to agent cluster. We could use spec magic and say "the agent cluster that contains the agent", but maybe it would be better to be more explicit and go via the browsing context group, etc.?

@domenic domenic added clarification Standard could be clearer topic: agent The interaction with JavaScript's agent and agent cluster concepts labels Jan 14, 2020
@annevk
Copy link
Member

annevk commented Jan 15, 2020

Duplicate of #4339?

@domenic
Copy link
Member Author

domenic commented Jan 15, 2020

I can't really understand #4339, but maybe?

@annevk
Copy link
Member

annevk commented Jan 15, 2020

You mean the text it's citing? It's the first step of run a worker:

Create a separate parallel execution environment (i.e. a separate thread or process or equivalent construct), and run the rest of these steps in that context.

@domenic
Copy link
Member Author

domenic commented Jan 15, 2020

Oh, I didn't realize it was citing text. That sounds pretty different than what I'm discussing in the OP of this issue, though, which is the current implicit definition of agent clusters via "can share memory with" equivalence relation, and agents via "allocate at the appropriate time".

@annevk
Copy link
Member

annevk commented Jan 16, 2020

Well, the intended solution is the same, but sure.

domenic added a commit that referenced this issue Mar 27, 2020
Closes #5210.

Closes #4339 by removing the explicit phrasing of a parallel execution
environment, instead relying on the agent infrastructure.

Closes #4988 by reintroducing a definition for "similar-origin window
agent", separate from its creation algorithm. Like the definition of all
agent types, it is now informal, just stating what globals are contained
in the agent.

Relocates the site-related definitions to the "Origin" section of the
spec, adjacent to the "schemelessly same site" and "same site"
definitions.

Exposes some of the higher-level concepts here to the dev edition.
domenic added a commit that referenced this issue Mar 31, 2020
Closes #5210.

Closes #4339 by removing the explicit phrasing of a parallel execution
environment, instead relying on the agent infrastructure.

Closes #4988 by reintroducing a definition for "similar-origin window
agent", separate from its creation algorithm. Like the definition of all
agent types, it is now informal, just stating what globals are contained
in the agent.

Relocates the site-related definitions to the "Origin" section of the
spec, adjacent to the "schemelessly same site" and "same site"
definitions.

Exposes some of the higher-level concepts here to the dev edition.
domenic added a commit that referenced this issue Mar 31, 2020
Closes #5210.

Closes #4339 by removing the explicit phrasing of a parallel execution
environment, instead relying on the agent infrastructure.

Closes #4988 by reintroducing a definition for "similar-origin window
agent", separate from its creation algorithm. Like the definition of all
agent types, it is now informal, just stating what globals are contained
in the agent.

Relocates the site-related definitions to the "Origin" section of the
spec, adjacent to the "schemelessly same site" and "same site"
definitions.

Makes event loop creation explicit during agent creation, now that they
are 1:1 per #5396 and #5416.

Makes "responsible event loop" a convenience accessor, instead of one of
the core algorithms of environment settings objects. This means that
individual environment settings object definitions no longer need to
specify how to retrieve the responsible event loop.

Exposes some of the higher-level concepts here to the dev edition.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Standard could be clearer topic: agent The interaction with JavaScript's agent and agent cluster concepts
Development

Successfully merging a pull request may close this issue.

2 participants