New tier-2 target for `wasm32-wasi` + threads

[abrown]

Proposal

Several of us working on WebAssembly (cc: @alexcrichton, @loganek, @sunfishcode, @sbc100, @AlexEne) have made progress on a WASI proposal to allow spawning threads in WebAssembly programs via a new WASI interface: wasi-threads. Several issues related to the proposal are still under discussion, but the core idea is implemented in at least two WebAssembly engines (Wasmtime and WAMR) and a subset of the pthreads API is supported for the C language via wasi-libc. I am opening this issue to request adding support for this in the Rust compiler.

Why a new target? wasi-threads relies on the WebAssembly threads proposal; modules built with threads enabled allow new features such as atomic instructions and shared memories. Not all users will want to allow threads-enabled programs in their environment but still will want to compile to wasm32-wasi: after some discussion here, we decided to use a new target triple to indicate that a program targets both WASI (including wasi-threads) and the WebAssembly threads feature.

In wasi-libc, this target is currently named wasm32-wasi-pthread but this name has not yet been released and could change. I would prefer, for simplicity, that the wasi-libc target and the rustc target were the same, so I can change the wasi-libc one if there are other suggestions here (e.g., wasm32-wasi-threads?). Let the bikeshedding begin...

What is more important is whether to approve this proposal: can we add a new target (very similar to wasm32-wasi) that allows us to implement wasi-threads in Rust? Some previous work on this includes getting the atomics build to work; eventually this looks like implementing Thread::spawn via wasi_thread_spawn. The new target gives us the ability to incrementally fill in the implementation details as wasi-libc and the wasi-threads proposal evolve.

Mentors or Reviewers

@alexcrichton

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[nagisa]

@rustbot second

I think it makes sense to add a target in this particular instance. Though, as I mentioned in the Zulip thread, I’m not sure what the most appropriate name for such a target would be, or how to steer code to continue using target_ CFGs to decide on specific behaviours and implementations rather than the target name verbatim.

[apiraino]

@rustbot label -final-comment-period +major-change-accepted