threads
threads copied to clipboard
WebAssembly
Consolidate agent/agent cluster definitions with ES spec?
See also https://github.com/tc39/ecma262/issues/887. This is mostly a concern for when this gets to the level of formal specification, not during the design phase.
It seems like it'd be a bad end state for two separate specs to define these concepts, when they're meant to operate on the same level. There are a variety of solutions here, but the one that seems easiest is to send appropriate PRs to the ES spec to make sure their concept is general enough, and then reference them.
The current approach for threads v1 wouldn't define any WebAssembly-specific agent. Developers would have to rely on web workers to create threads. Given this approach, I think your proposal would be tied to v2 (or whenever we do wasm-specific threads), correct?
I was mostly reacting to the definitions of agent/agent cluster in https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md. I assumed those were on target to be part of the spec.
@domenic, I think the consensus is more or less that the v1 threads spec should remove any prose that was partially excerpted from the ES spec and just defer to the ES spec instead. (Notably for agents and memory model.) Some discussion of this problem at https://github.com/WebAssembly/threads/issues/25#issuecomment-305159097 et seq.
On 15 June 2017 at 07:50, Lars T Hansen [email protected] wrote:
@domenic https://github.com/domenic, I think the consensus is more or less that the v1 threads spec should remove any prose that was partially excerpted from the ES spec and just defer to the ES spec instead. (Notably for agents and memory model.) Some discussion of this problem at #25 (comment) https://github.com/WebAssembly/threads/issues/25#issuecomment-305159097 et seq.
That seems reasonable for the design docs for the time being. But I'm a bit puzzled how that approach would be possible for the actual spec. Remember that the core Wasm spec is independent from JavaScript as an embedding, so ultimately needs a sufficiently self-contained definition of these notions. They would be connected to ES in the Wasm JS API spec.
I think that's why Ben added that prose to begin with - to keep it independent. But when Wasm is embedded in JS it becomes confusing if the prose in the Wasm spec does not reasonably match what's in the JS spec, so more care is needed in the Wasm spec.
Longer term, if Wasm-embedded-in-JS does not have an agent / agent cluster / memory model that matches JS well, things will get messy. Should the Wasm spec provide some hooks where an embedder can attach behavior? That's effectively how the ES spec deals with the fact that JS is running sometimes in a browser, sometimes not. The agent / agent cluster formalism is pretty high level, there's no mention of how agents are instantiated, nor of why an agent may have [[CanBlock]] set to false, say.
Yes, providing the right hooks makes total sense. And of course the semantics should match. Whether that necessarily allows avoiding duplication or requires matching definitional wording literally is a slightly different question. We might need to allow ourselves sufficient room to manoeuvre and avoid creating path dependencies on TC39.