Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Threads #5

Closed
skyne98 opened this issue Mar 29, 2019 · 8 comments
Closed

Threads #5

skyne98 opened this issue Mar 29, 2019 · 8 comments

Comments

@skyne98
Copy link

skyne98 commented Mar 29, 2019

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
Copy link
Member

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

@skyne98
Copy link
Author

skyne98 commented Mar 29, 2019

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

@sunfishcode
Copy link
Member

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
Copy link

yagehu commented Aug 12, 2020

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
Copy link
Member

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
Copy link
Contributor

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

@sunfishcode
Copy link
Member

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.

kildom pushed a commit to kildom/clang-wasi-port that referenced this issue Jul 14, 2021
@abrown
Copy link
Collaborator

abrown commented Mar 13, 2023

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.

@abrown abrown closed this as completed Mar 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants