Is this proposal necessary?

[abrown]

Not everyone may believe that a separate WebAssembly proposal for spawning threads is a good idea. Perhaps the status quo is sufficient or other concerns (e.g., non-determinism) are more important. Others may be convinced that this is necessary. I'm opening this discussion to hear both sides of this question ‐ is this proposal necessary?

[conrad-watt]

I think this proposal is necessary in the broad strokes. I don't think there's a strong non-determinism argument against this proposal as we already have shared memories and Web workers.

One thought (which I'd be happy to spin out into a separate issue): one argument that may come up against this proposal is that in the wider Web platform community, APIs and language features are generally prohibited from observably carrying out/creating concurrent execution - Web workers are considered specially blessed to do this. In theory, a minimal Wasm proposal could work with just shared functions without a spawn instruction, as the spawn functionality could be provided by the host (i.e. Web workers on the Web). This may get the proposal out of the door slightly faster, and then Web platform arguments around spawn could be quarantined to a post-MVP discussion.

[conrad-watt]

I agree that we definitely want a native Wasm spawn instruction in the fullness of time, but pushing for it immediately has two main downsides:

• We have to engage Web platform people outside Wasm to get their nod of approval, and this may involve a variety of expensive conversations
• We have to solve the design question of how rich the native representation of a thread is in Wasm, how many control/sync instructions are needed, and related questions (e.g. How should threads early-exit? #7)

Personally I think we'll have our hands full pushing through the appropriate changes to postMessage and ensuring browsers are happy with the GC implications of shared (notwithstanding V8's current experiments in this direction). I don't think it would be particularly wrong to consider the above additional questions upfront, but my perception is that the non-Web community wants non-instance-per-thread concurrency ASAP, and working through the above eagerly would extend the timeline.

[lukewagner]

(Oops, deleting and moving this comment into the reply thread.) I think the second bullet is mostly orthogonal to whether we add a thread.spawn or not (we can have a minimal set of control/sync instructions in any case). The first bullet is indeed something that will have to be discussed to carefully with the HTML spec folks to make sure pure wasm threads are properly integrated into the spec's current semantic framework for threads/workers, but it seems like that is a discussion we should start sooner rather than later, and only consider removing thread.spawn if it ends up being a blocker, rather than pessimistically assuming it'll be a blocker.

[conrad-watt]

I think the second bullet is mostly orthogonal to whether we add a thread.spawn or not (we can have a minimal set of control/sync instructions in any case)

Somewhat, but I think a greater space of solutions would be acceptable in API-space - for example a WASI API could probably key its terminate, etc thread management functions off i32 tids, whereas I think we'd need a dedicated thread type for similar operations in core Wasm.

[tlively]

I think this proposal is necessary in the broad strokes.

I'd be curious to hear why this is. I personally don't see a problem with allowing everything in a module to be shared, but still having thread spawn be an imported capability. Keeping spawn an import seems more in line with Wasm's goal of not providing ambient access to the computing environment.

[conrad-watt]

I wasn't being very careful with my wording here. I think a post-MVP threads proposal that introduces shared functions, globals, and tables is necessary. I accept that the version of the proposal without thread.spawn is probably more immediately palatable for the Web platform, and I'd be fine with this.

[kripken]

I am very much in favor of the shared additions in this proposal - shared Tables, shared Globals, etc. - as (if those can work on the Web) then we could use them to greatly simplify things like pthreads + dynamic linking!

I am less certain about an actual instruction to spawn a thread, because while a pure-wasm thread could be lighter-weight than a Web Worker today, we actually need the heavyweight JS parts, since that JS is the only API surface the wasm has. It is very common for threads to do things like:

• get the current time
• make a random number
• do a network access
• do some console.log for debugging

All those require a JS environment.

Concretely, if we think this makes sense on the Web then we'd need to have a plan for how such lightweight threads access APIs. I don't have a good idea myself there.

One option is proxying their requests to another thread to access JS for them. This was actually how PNaCl worked, and it had large downsides - asm.js and then wasm improved on that by allowing direct synchronous access to Web APIs. Emscripten does have such a proxying mechanism that we can use (we use it today to proxy to the main thread for things that only work there, and other things), and it is heavily optimized, but it is still slow. In fact, we are doing a lot of engineering to reduce the amount of proxying that we do (e.g. in the WasmFS project). Overall, I think proxying is not promising, but maybe there are other ideas.

[kripken]

I've been assuming that we (incrementally) start doing Conrad's option 2 above, marking functions as "shared" (I expect in WebIDL, similar to how we opt in [AllowShared] today),

Perhaps I don't understand how that would work. Even if we marked fetch() that way - how would it be called from wasm? Or, if we want to ignore async, the WebGL API? (Perhaps there are JS discussions I'm not aware of?)

Btw, to be clear, I'm not opposed to thread creation in core wasm - I'm neutral on it. But I do see great benefit to shared Tables and Globals, so I agree with @conrad-watt that it makes sense to start there.

[lukewagner]

fetch can be imported directly by wasm today with type (func (param externref externref) (result externref)) (I haven't thought through how to use JSPI). There are still the long-standing challenges of allowing wasm to pass a non-undefined receiver and create values efficiently from linear memory, but we should provide solutions to those in any case (through JS API extension). As I said above, this is a somewhat longer incremental path of increasing the set of Web APIs accessible directly and efficiently from wasm, but unless one thinks that JS glue code is necessary forever, this seems like positive progress towards the goal state of well-integrated wasm on the Web Platform.

[kripken]

There are still the long-standing challenges of allowing wasm to pass a non-undefined receiver and create values efficiently from linear memory, but we should provide solutions to those in any case (through JS API extension).

If we provide JS APIs for wasm to import to build the string and object parameters to fetch(), wouldn't we still require a JS environment to implement strings and objects there?

unless one thinks that JS glue code is necessary forever, this seems like positive progress towards the goal state of well-integrated wasm on the Web Platform.

Our goals might differ. I am actually optimistic about using JS alongside wasm in the long term, since while it adds some overhead it also reduces other overhead. For example, using the JS standard library helps reduce wasm code size, for things like strings, date/time, randomness, etc.

With that said, if we find a good way to run wasm without JS on the Web, that could be useful too.

[lukewagner]

More discussion (than probably belongs in this thread) is needed, but I think there are a variety of ways to specify things so that wasm can create the values it needs to make the Web IDL calls without pulling in a whole JS engine. Also, I agree with you that, to minimize code size, it's important to continue to allow wasm to import various JS-provided library primitives (esp. Intl!); I think this is also achievable by exposing these libraries as built-in modules possibly mirrored in Web IDL. Again, this is a longer path, but I think it's a valuable one to make wasm a first-class citizen of the Web platform.

[kripken]

Sounds interesting. Happy to discuss offline.

[rossberg]

Three points from my perspective:

1. On the web, thread.spawn wouldn't replace JS-side worker creation, but complement it. As said above it e.g. is much more lightweight.
2. Wasm must be fully functional without a JS environment. So there ought to be a way to create threads without JS.
3. Threads are purely a computational resource, very much like memory. It hence is natural and in line with Wasm's design to allow allocating them with dedicated instructions.

That said, I agree that this can be separated from adding sharability to the type system. How fine-grained we make proposals is a question of considerable administrative overhead, however.