meta: Stabilize WASI support

[carllerche]

This tracks outstanding issues to stabilize WASI support for Tokio.

Initial PR: #4716

Known issues:

• tests were disabled and need to be re-enabled
• tokio::time can be stabilized.
• Use target_family = "wasm" once MSRV becomes 1.54. Current workaround: #4865
• WASI lacks many APIs needed for getting Tokio examples working
  • TcpStream::connect
  • TcpListener::bind

Refs: #1597

[rjzak]

1. Since Support Webassembly #1597 was closed, perhaps track the differences between the three WebAssembly targets supported by Rust:
   • wasm32-unknown-emscripten
   • wasm32-unknown-unknown
   • wasm32-wasi
2. Also, add an integration test which:
   • Compiles a test application in Rust to Wasi which accepts connections
   • Runs the test Wasi application (via Wasmtime library)
   • Connect and ensure it worked
   • Cleanly shutdown the Wasi app
3. Add wasm32-wasi CI test: cargo hack test --each-feature --exclude-features rt-process-signal,rt-multi-thread,rt-net --target=wasm32-wasi (currently has an unused code complaint in the Runtime module for one of the combinations)

[MediosZ]

For missing APIs like TcpStream and TcpListener, I tried to replace std with wasmedge_wasi_socket and it works.
But this requires using WasmEdge and is not compatiable with other runtimes.
Some refs:
mio
tokio

[umgefahren]

Since WASM Threads are already support by Rust Std (although in nightly with build std) would it be possible to bring the multi thread runtime to WASM?

[Darksonn]

I'm sure we will support it eventually, but it is not a priority right now.

[frewsxcv]

Since WASM Threads are already support by Rust Std (although in nightly with build std) would it be possible to bring the multi thread runtime to WASM?

@umgefahren Do you have a link to the PR where this was implemented in std?

[rjzak]

There is some code for Wasm threads, but most of it is empty or unsupported: wasm/atomics/thread.rs.

The same is true for Wasi, wasi/thread.rs.

There has been some progress on Wasi threads, the Wasi-Libc project has some pthread functions https://github.com/WebAssembly/wasi-libc/search?q=pthread, but most seem to be in the musl library. Even if Rust or C had code for Wasi threads, this still requires a Wasi runtime to be able to use it, and I don't think we're there yet.

[milesrichardson]

has anyone tried somehow replacing threads with web workers? intuitively that seems like it would work. I don't know enough about Tokio or Rust to say for certain, but it seems like a natural fit considering that "the Worker interface spawns real OS-level threads".

I searched for "wasm threads web workers" which led to some prior work with emscripten (e.g. https://github.com/boyanio/wasm-workers). Looks interesting. Also gregbuchholz/threads looks promising, claiming successful multi-threading in the wasm32-unknown-emscripten target.

I also found the WebAssembly/threads repository with proposals and discussion around adding threads to WebAssembly. That would be cool, but until then, is there any reason why a runtime like Tokio couldn't provide a Thread implementation for platforms that support the Web Worker API?

Is the idea to basically implement std::Thread for the wasm target (sys/wasm/atomics/Thread) with some platform-specific analog to a "thread" (see the Unix implementation for example)?

This sounds feasible, at least in terms of the features available to Web Workers, like postMessage, transferrable objects, SharedArrayBuffer, Atomics, etc.... right?