The big gundown

[lars-t-hansen]

The spec says: "An embedder may terminate an agent without any of the agent's cluster's other agents' prior knowledge or cooperation."

Can we define "embedder" more precisely here? Are we talking about the browser or the surrounding (in a browser context) JS application? Either? I've worked fairly hard for no-notification killing not to be allowed in the HTML/JS space, where the embedder/embeddee concept is easier, and although I'm not sure I've succeeded completely, I've at least succeeded in removing prose from the HTML spec that allows workers to be gunned down at random.

And while I'm here, "prior"? Is there any kind of post-hoc notification facility intended?

It might be interesting to have a discussion about why this prose is here. It is one thing for the agent itself to do something silly so that it traps (OOB); another thing for the embedding to remove an entire cluster; a third thing for an embedding to remove a single agent within the cluster, which IMO is bad.

(Also, what is "terminate"? The issue also comes up here, WebAssembly/exception-handling#16)

[lars-t-hansen]

Since we're talking about the embedder, later we read:

"The embedder is also permitted to suspend or wake an agent. A suspended agent can be woken by the embedder or the wake operator, regardless of how the agent was suspended (e.g. via the embedder or a wait operator)."

Again there's a bit of an issue about who the embedder is and whether this is intended to make wait/wake in wasm interact-able with wait/wake in JS: Can I wait in wasm and wake the thread with Atomics.wake from JS? Vice versa?

[binji]

The spec says: "An embedder may terminate an agent without any of the agent's cluster's other agents' prior knowledge or cooperation."

It looks like I took this from the ES spec: https://tc39.github.io/ecma262/#sec-agent-clusters

My intention was to have some minimal discussion of agents and clusters for the overview. But perhaps my stripping down of that text just serves to confuse.

Can we define "embedder" more precisely here? Are we talking about the browser or the surrounding (in a browser context) JS application? Either?

I see "embedder" as meaning anything external to the WebAssembly implementation. But you're right, it is vaguely defined currently.

Can I wait in wasm and wake the thread with Atomics.wake from JS? Vice versa?

This is the intention, yes.

[lars-t-hansen]

On Mon, May 29, 2017 at 11:32 AM, Ben Smith ***@***.***> wrote: The spec says: "An embedder may terminate an agent without any of the agent's cluster's other agents' prior knowledge or cooperation." It looks like I took this from the ES spec: https://tc39.github.io/ ecma262/#sec-agent-clusters My intention was to have some minimal discussion of agents and clusters for the overview. But perhaps my stripping down of that text just serves to confuse.

Indeed that is word for word what the ES spec says, but the rest of the paragraph is actually the important bit: "If an agent <https://tc39.github.io/ecma262/#agent> is terminated not by programmatic action of its own or of another agent <https://tc39.github.io/ecma262/#agent> in the cluster but by forces external to the cluster, then the embedding *must* choose one of two strategies: Either terminate all the agents in the cluster, or provide reliable APIs that allow the agents in the cluster to coordinate so that at least one remaining member of the cluster will be able to detect the termination, with the termination data containing enough information to identify the agent <https://tc39.github.io/ecma262/#agent> that was terminated." Effectively, this is a prohibition on killing agents without providing a means for the cluster to be told.

Can we define "embedder" more precisely here? Are we talking about the browser or the surrounding (in a browser context) JS application? Either? I see "embedder" as meaning anything external to the WebAssembly implementation. But you're right, it is vaguely defined currently.

Either interpretation is OK with me in principle but it becomes an issue when we write the prose for what happens when an agent is killed by the embedding. If it's the browser that kills it then the browser must provide some kind of mechanism for the wasm (or JS on its behalf) to discover that; if the JS kills it, then JS can directly notify the wasm of this fact. I don't want to come across as too hard-nosed here because the wording in the ES spec has ruffled some feathers already, and what is a "reliable API" anyhow? But for the sake of stability it is not good to allow the embedding to just remove some of the agents that are operating without some kind of notification.

Can I wait in wasm and wake the thread with Atomics.wake from JS? Vice versa? This is the intention, yes.

Makes sense. I have not spotted anything that would seem to make that impossible; just curious.

…

--lars

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEmYlidxpeA8DHba1KDRilr3RKid6zNaks5r-pDEgaJpZM4NpAxR> .

[binji]

OK, this makes sense. I'm not sure how we'll provide a mechanism for notifying wasm when an agent is killed, though. Perhaps you're right that it's enough that the notification can be sent to JS and forwarded to wasm if needed.

[jfbastien]

The big question probably is: can an implementation kill some agents but not others? Where's the boundary where agents can be killed? Origins? I think service workers were having that discussion.

[lars-t-hansen]

Summoning @domenic @annevk, who know a lot more and who made this work out for HTML.

In general, the implementation (call it the browser, for the sake of concreteness) should not willy-nilly remove agents in a cluster without removing the entire cluster. The web workers spec used to allow that but no longer does. The browser can remove entire clusters (eg, a ServiceWorker and its descendant dedicated workers) but that's fine.

The subtleties come in with situations where the user performs an action that removes part of the cluster. Two windows (tabs, documents) A and B may be in the same cluster if one was opened from the other and they are domain-compatible; in this case they share the event loop, and they may share memory, and one may be waiting on a computation in the other, indeed a worker in A may be blocked on a shared-memory location and will expect to be woken by some agent in B. The user may take an action that closes B, removing the agents in B from the cluster by "non-programmatic action". In this case it is in principle possible for the designer to have set up unload actions in B so as to allow A to be notified, so the letter of the spec is satisfied. I mostly believe that similar notification is possible in all cases where it matters, on the web platform.

We can't easily disable the sharing of memory between A and B since B can just reach into A's global object and read its global variables, and obtain a pointer to a shared memory that way.

Wasm could perhaps sidestep the problem by decreeing that shared memory use in wasm is only well-defined in situations where no agents will be killed by the implementation without the entire agent cluster being killed; for the web platform this would mean sharing memory only among a window/serviceworker/sharedworker and its dedicated workers, never cross-window. The restriction is not onerous in practice. We could perhaps give it some teeth, by checking at module instantiation time that all instantiations obey the rule. But it would not prevent JS from sharing the memory more widely, and since JS can wait/wake on memory shared with wasm, the problem isn't really gone.

[annevk]

whatwg/html#2581 is the relevant HTML issue (and matches the above description of the problem). There's some possible API ideas there, but nobody's working them out as far as I know.