-
Notifications
You must be signed in to change notification settings - Fork 32
DOM/HTML integration: How can the agent cluster grow? #154
Comments
Also needs to be reflected in the main spec's "Web browser embedding" section, which is currently sketchy. |
As far as I can tell in such situations it's not the agent that's being terminated, but it's just a single global object within that agent. |
@annevk, can you elaborate a little? I don't understand your comment. |
I was responding to
As you already addressed the shared worker scenario. While you can remove an iframe (and thereby make its global inaccessible), any objects you hold references to, including the global, will be there still. |
Remaining agent termination issues are whatwg/html#2581 and tc39/ecma262#401. |
Closing this, as issues have migrated to more appropriate repos. |
An agent creates a SharedArrayBuffer. In a DOM/HTML setting, which other agents can it share that memory with?
The spec requires that memory be shared only so that agents in the cluster are suspended or terminated together. The canonical situation where that is not the case is for a window and a sharedworker it communicates with - that worker may remain alive even if the window is closed, or suspended because it's pushed into its tab's history. Then, if the window is holding a lock (in shared memory) the sharedworker may deadlock.
The rule of thumb has therefore been that a cluster has to comprise a window and its dedicated workers (recursively) or a SharedWorker and its dedicated workers (recursively) and that attempts to share memory outside such clusters must be prevented.
But are there other situations where the co-termination restriction is not violated? I'm thinking of a top-level window and a nested element such as a window in an iframe, or similar situations.
The text was updated successfully, but these errors were encountered: