Hacker News Reader

Comment by jesse__ | Hacker News Reader

Not sure what the Rust situation is like, but last I checked (and compiled a non-trivial personal application) WASM supported the pthreads API and it seemed to work reasonably well. Have you encountered stumbling points porting a heavily MT Rust program to WASM?

View on HN

That's supposedly WASI, an interface specifically designated for system programming use, and that's where it implements part of the POSIX support including pthread.

OTOH you still need to start a wasm runtime first, then import the WASI module into the wasm host.

P.S.: used to tinker with wasmtime and wasmi to add wasm support to my half abandoned deno clone ;) I learned this the hard way

WASI does not implement POSIX. And it isn't the goal of WASI to implement POSIX. It does not support pthreads either. WASI is similar to POSIX because its an API that provides a "system interface" for WASM programs. But the API is much simpler and quite different and capability based. There are things like WASIX (by Wasmer) built on of WASI that aims to provide POSIX support for multiple languages

I think GP was probably using Emscripten

Correct

WASM itself does not support pthreads. However things like Emscripten have very good support for pthreads. WASM is one of the compilation targets of Emscripten (we had asm.js before that) and on top of that emscripten provides excellent shims for many POSIX APIs. Regarding Rust which has supported WASM as a compilation target for a long time now, the idiomatic way of doing this is not shiming, but using higher level APIs: if you need parallel execution threads and need to compile to WASM you would use a crate (such as rayon) that is able to compile to WASM (and will use web workers under the hood just like Emscripten does). You would not use pthreads directly (std::thread)

WASM does not support pthreads in the browser, only web workers, which are much more limited.

Reply on news.ycombinator.com