Tracking issue for end-to-end wasi-threads support

[abrown]

Several of us (@loganek, @sunfishcode, @sunfishcode, @haraldh) have been working towards implementing all of the pieces to demonstrate an end-to-end wasi-threads example. The current direction is to implement this in Wasmtime, though @loganek has also opened a PR to do so in WAMR (#1638). To that end, this issue is meant to track all of the various parts needed not only to show a proof-of-concept, but to upstream enough code for (fearless) users to try out this new functionality. I do not expect this to be a comprehensive plan, but only to implement what is necessary for the "stage 1" functionality described by @alexcrichton here (i.e., no component model integration).

We can split this into areas and I've made an effort to try to order the tasks within these.

Specification

• spec: consider adding wasi_thread_exit for early return from a thread (#7); will require some implementation in wasi-libc and wasmtime
• spec: fix CI issues (#26)

Toolchains

• toolchain: allow importing and exporting the same memory in wasm-ld; done in D135898
• toolchain: allow compiling programs with wasm32-wasi-threads (#326); in progress at #331 and #274
• toolchain: teach the toolchains to import shared memories by default; it seems most natural to have both the parent and child threads import a memory versus exporting it ¹; under discussion at #502

Libraries

• wasi-libc: only run C constructors once (#339); ready to merge
• wasi-libc: initial thread-local values must be memcpy-ed to the TLS area; this seems to be handled by some combination of #342 and #343
• wasi-libc: resolve spinlock questions to merge pthread spinlock support (#324)
• wasi-libc: create a way to run libc-test tests; in progress at #369
• wasi-libc: audit for any missing pthreads APIs — the fundamentals are there but we need to determine what functions remain to be enabled

Engines

• wasmtime: implement wait and notify; on Linux, this could use futex as done here by @haraldh but we need a solution for all OSes (also, is the 32-bit limitation a problem?)
• wasmtime: avoid mutation of buffers/strings passed in to host functions by Wiggle; #5054, #5225, #5229 #5264, #5268
• wasmtime: fix validate_atomic_addr; #5063 #5239
• wasmtime: wasi: provide thread-safe implementations of WASI contexts bytecodealliance/wasmtime#5235
• wasmtime: implement wasi-threads; in progress at #5484

I'm completely open adding/removing/editing the items above as well as moving this issue somewhere else but I felt it would be helpful to keep track of the state of things.

Footnotes

1. this also likely involves figuring out a better place to create the shared memory initially in Wasmtime (instead of here) ↩

[haraldh]

• wasmtime: implement wait and notify; on Linux, this could use futex as done here by @haraldh but we need a solution for all OSes (also, is the 32-bit limitation a problem?)

So, there is the atomic-wait crate written by Mara Bos. Here is what she wrote about the other OSes:

Cross platform atomic wait and wake (aka futex) functionality.

This crate only supports functionality that's available on all of Linux, Windows, and macOS. That is:

• Only AtomicU32 is supported. (Linux currently only supports 32-bit futexes.)
• Only the "wait", "wake one", and "wake all" operations are supported. (Linux supports more operations, but Windows and macOS don't.)
• No timeouts. (macOS doesn't have a stable/public API for timeouts.)
• The wake operations don't return the number of threads woken up. (Only Linux supports this.)

So I don't know what OS the person used, whoever specified memory.atomic.notify, memory.atomic.wait32 and memory.atomic.wait64.

[haraldh]

wasi_thread_kill would also be a good extension

[sbc100]

wasi_thread_kill would also be a good extension

Do you mean pthread_exit, or something to implement pthread_cancel or something to implement pthread_kill (which is oddly names since it delivers signals and doesn't control the lifetime of a thread).

[haraldh]

wasi_thread_kill would also be a good extension

Do you mean pthread_exit, or something to implement pthread_cancel or something to implement pthread_kill (which is oddly names since it delivers signals and doesn't control the lifetime of a thread).

Yeah, something to implement pthread_cancel I had in mind.

[sbc100]

So there are two types of pthread cancellation: DEFERRED and ASYNCHRONOUS : https://man7.org/linux/man-pages/man3/pthread_setcanceltype.3.html.

IIUC deferred cancellation is much simpler and doesn't need any OS support, its all implementable in user space. Async cancellation is much harder and normal relies on some kind of async signal primitive under the hood. I have previously proposed that we simply ignore asynchronous cancellation since async signal very different to anything that exists in wasi/wasm today. I would also argue that very few real world program depend on it, but my information here is obviously not complete.

[abrown]

wasmtime: implement wait and notify; on Linux, this could use futex as done here by @haraldh but we need a solution for all OSes (also, is the 32-bit limitation a problem?)

@haraldh, it looks like V8 bottoms out in their own FutexEmulation implementation, which is used for all platforms, even Linux.

[abrown]

I've created bytecodealliance/wasmtime#5274 to make a way to measure how much (or little) locking will affect WASI performance.

[turbolent]

Once spec or some form of docs/description, and some example/test binaries are available, I'd love to implement support in https://github.com/turbolent/w2c2.

[loganek]

Once spec or some form of docs/description, and some example/test binaries are available, I'd love to implement support in https://github.com/turbolent/w2c2.

@turbolent This might be helpful: #11

[yamt]

in this weekend, i implemented wasi-threads for toywasm.
while it still has rough edges, it can run toywasm itself built for wasi, which uses pthread with the latest wasi-sdk.

[turbolent]

@loganek Thank you, I'll give that a try 👍
@yamt Congrats, great work!