-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Comments
Duplicate of #4339? |
I can't really understand #4339, but maybe? |
You mean the text it's citing? It's the first step of run a worker:
|
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". |
Well, the intended solution is the same, but sure. |
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.
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.
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.
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:
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.?
The text was updated successfully, but these errors were encountered: