Move a `wasm32-wasi-preview1-threads` target to tier 2

[loganek]

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.

[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

[sunfishcode]

In the blog post introducing wasi-threads support in wasmtime and wasi-sdk, @abrown wrote:

https://bytecodealliance.org/articles/wasi-threads

"Remember that wasi-threads, as a new WASI proposal, is still experimental — do not expect strong stability in the ABI, especially as WASI transitions to the component model."

From Wasmtime's perspective, the conditions which motivated @abrown to say this are still present. We said up front when wasi-threads was starting that the instance-per-thread model would not be workable for us, and that an approach such as thread-spawn would be workable. Wasi-threads has been useful in enabling experimentation, and supporting development of infrastructure for shared memories, but it's not something we guarantee will be supported for the long term in its current form.

[loganek]

@sunfishcode indeed the proposal is not a long-term solution. However, I don't think it doesn't mean we should not stabilize it and have it as an extension for (I guess) a number of usecases that need multi-threading support in their Wasm applications. Even though there's an active work on the thread-spawn proposal, it is still in an early stage. There will be runtimes (or instances of runtimes) that will support wasi-threads for a while, so from this perspective I think it makes sense to keep it around.

I've briefly discussed this with @abrown already and he seems to agree on finalizing wasi-threads, but I'm happy to discuss the concerns further if needed.

[abrown]

My opinion on this should be pretty non-controversial here and probably doesn't sway things either direction: I'm committed to working on threads in WebAssembly, whatever form that may take, which is why I've contributed both to wasi-threads and thread-spawn. I'm going to be fine with whatever the community decides for either of those proposals; I completely understand the "instance-per-thread" problems @sunfishcode mentions and I am also sympathetic to the "meanwhile let's experiment with wasi-threads" argument @loganek is making. We probably need to hash out a clear plan in the WASI subgroup (or somewhere?) and there's more opinions than mine here.

But I do think we should head over to the Zulip stream to discuss this further before some Rust maintainer kicks us out of here 😁

[wesleywiser]

@rustbot second

As mentioned, #574 already approved the idea of making this target Tier 2. Marking the target as Tier 2 does not commit us to shipping the target for any specific amount of time and the preview description in the name should help make users aware that this target is more in flux than many of our other targets. Thus, in the future, if we need to make significant changes to the target or drop it entirely, that is fine (but we should try to avoid unnecessary breakage 🙂). I don't see any reason not to continue forward with making this a Tier 2 target at this time.

[wesleywiser]

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