Proposal

The support for wasm32-wasi-preview1-threads target was added to a compiler as part of the PR: rust-lang/rust#112922. The target extends wasm32-wasi target (soon becoming a wasm32-wasi-preview1 target: rust-lang/stdarch#1417) by adding support for spawning threads based on the wasi-threads proposal. The wasm32-wasi-preview1-threads target uses the same source code as wasm32-wasi target for stdlib, but it enables additional flags (+atomics,+bulk-memory,+mutable-globals) and links against wasm32-wasi-threads libraries from WASI-SDK.

It was decided by the community that wasi-threads proposal will not proceed to the next stage as the threading support will be in the future added to Core WebAssembly standard (WIP proposal: https://github.com/abrown/thread-spawn). Given the early stage of the new, thread-spawn proposal, the wasi-threads proposal will be finalized even though it doesn't become part of WASI standard (so teams with a need for threading support can use it for the time being).

We propose moving the target to tier 2, given that:

• The target was already approved in the past as Tier 2 target: New tier-2 target for wasm32-wasi + threads #574 (and renamed here: Rename wasm32-wasi target to wasm32-wasi-preview1 #607), but it was decided during the review of WASI threads, implementation of wasm32-wasi-preview1-threads target rust#112922 to start as Tier 3 target
• the wasi-threads was already implemented in at least 4 different WASM runtimes: Wasmtime (behind --wasi-modules=experimental-wasi-threads flag), WAMR, wasmer and toywasm
• WASI-SDK already relies on wasi-threads proposal for the Pthreads implementation

The reason behind adding a new target as oppose to using existing wasm32-wasi / wasm32-wasi-preview1 was well explained in the original MCP: #574

There were also concerns raised by the community regarding adding this target in general, but they are addressed below:

• wasi-threads is not part of the standard, and thus, experimental - as mentioned above, the proposal wasn't included in the standard, but there's an ongoing effort to finalize it and keep it as an extension of WASI snapshot preview1.
• we might end-up with multiple WASM targets for supporting various set of features - Threads support is quite different to other extensions, as enabling it affects the implementation of the standard library. There are not many proposals that affect either the implementation of standard library or the ABI, so we don't think it is a concern.

We have reviewed the requirements for the tier 2 targets. The target meets all of the requirements except for documentation gaps which will be added if the MCP is accepted.

Our team at Amazon Prime Video will run tests regularly and fix build failures.

Mentors or Reviewers

@pnkfelix

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.