Threads

[skyne98]

Hey there, does wasi have support for threads at the moment? Looking at current experimental wasi target for rust, look like no but this might just be a limitation of an experimental target.

Thanks!

[sunfishcode]

That's right, the WASI libc does not support threads at the moment.

[skyne98]

@sunfishcode is there support planned or it will be one of the "modules" for the spec mentioned in the article?

[sunfishcode]

There are really two levels of thread support. One is whether you can write a library that can be used within an application that uses threads, and the other is whether you can write a full multithreaded application.

For the library use case, WASI itself doesn't need to add anything, as the needed features -- atomics, wait, notify, are all provided by the core WebAssembly platform. WASI libc will need to be made threading-aware, but that should be straightforward.

(There are some extra features, such as the ability to have poll_oneoff be able to wait for a wasm notify, which could be added, which would need extra WASI support, but they're not needed for basic threading support.)

For full applications, you'll need the ability to create and join threads. In the WebAssembly threads proposal, these are left to the embedder. So, one possible way forward here is for WASI to add thread create and join functions to support this. We're still working out what the right granularity should be for API modules, but offhand, putting these in their own API module doesn't seem unreasonable.

[yagehu]

I'm curious about the status of threads for WASI as well. Is there a timeline? How do I find out more about the process? I'm new sorry if this is documented elsewhere.

[sunfishcode]

See WebAssembly/WASI#296 (comment) and the following comments. The basic situation is, wasm threads were designed to be built on Web Workers, which requires they create one instance per thread. People generally agree that for non-Web wasm (and possibly also Web wasm), we want a "native" threads feature, which would allow us to have one instance that has multiple threads, but at the moment no one has volunteered to champion that at the core wasm spec level.

Some people have asked about whether we could create minimal <pthread.h> compatibility which doesn't create new threads but allows programs using it to compile. That's doable, and needs someone to volunteer to do it.

Some people have asked about whether WASI could define an API that works with Worker-style threads as a temporary measure. That's also doable, though that would also depend on someone volunteering to do the work of designing and implementing it, and also of helping with the transition to "native" threads once they become available, because they probably won't be compatible, and transitions take work.

[lygstate]

@sunfishcode I am intersted on llvm-libc based wasi-sdk, is that a possible idea?

[sunfishcode]

It's my understanding that LLVM libc is very incomplete at this time, however it probably is possible. To be sure, that wouldn't change anything with respect to WebAssembly/WASI#296 (comment), or Worker-style threads. To support threads, one would need to do the same work regardless of which libc is used.

[abrown]

Things have changed: over the last few months, several of us have added a wasm32-wasi-threads target to wasi-libc which is now available as a pre-release in the wasi-sdk-20+threads artifacts. More instructions for how to use this new target are available here; please experiment and let us know any feedback either here or in the wasi-libc repository. I'm going to close this issue since I expect further conversation to be bugs or feature requests on top of that work.