`std::thread` support
Closed this issue · 6 comments
Right now, using std::thread::spawn leads to panic. I'm aware that wasm32-wasi doesn't have thread support, but wasm32-wasi-preview1-threads does. Is there any way to use threads on the browser?
WebAssembly.memory and web workers allow parallelization on the web. Does jco make the use out of them right now? If not, where should I start to contribute?
Hi there, thanks for asking! wasm32-wasi-preview1-threads adds experimental support for threads to the WASI Preview 1 target. Jco, Wasm Components, and the Component Model all target WASI Preview 2, which does not yet have support for threads.
The current work on thread support for WASI Preview 2 is tracked in the wasi-threads repo. This builds on the Wasm Core Threads proposal. Right now it's still too early to try and implement wasi-threads since the spec is still very much in progress. We'll want to wait for the spec authors to green light the spec as ready to implement before we try and implement anything.
So unfortunately right now there's nothing we can do here. But my hope is that after the Preview 2 release threads become a priority, and we'll be able to add experimental support for it as soon as the spec authors believe we should.
It's a sad thing that the wasi-threads proposal is not even reaching phase 2 after a year... but I get the point. Thanks!
See WebAssembly/wasi-threads#48 (comment) for more context
Please excuse me for continuing the discussion.
Reading the link above, it's now clear that wasi-thread and wasm-core-thread are being proposed separately. Also, wasi-thread seems to have concerns that it might be deprecated by wasm-core-thread.
wasm-core-thread(If I'm right) has reached phase 4 a few weeks ago, while wasi-thread is still at phase 1, worrying about its incompatibility with the component model.
If jco is it purely focusing on wasi-thread, would we wait for wasi-thread proposal to reach phase 4 as well? I guess it would take years, considering the slow momentum happening at that repo.
If jco is it purely focusing on wasi-thread, would we wait for wasi-thread proposal to reach phase 4 as well?
Part of the acceptance criteria for any WASI proposal is that it has multiple implementations. I don't expect us to want to wait for the proposal to reach phase 4 before implementing, but instead implement it sooner in order to help the proposal progress through the stages.
I haven't been in the room for the WASI Threads presentations and discussion, but my understanding is that the current plan is what I shared earlier: support for threads needs to land in Wasm Core first. And then thread spawning support for WASI and Wasm Components can be implemented in terms of that. I wouldn't worry too much about specific stages and timelines; for several members of the ByteCode Alliance this is one of the highest priority items after the Preview 2 release. That means work on it is likely going to be funded, and we might see it progress relatively fast.
The importance of thread spawning to our users is very well understood, and it is being prioritized above many other worthy tasks right now.
wasm-core-thread is just a spec proposal about the behavior of threads, it does not cover the behavior of creating threads. @abrown, @sbc100, and @conrad-watt are exploring a proposal for core wasm covering thread creation here https://github.com/abrown/thread-spawn .
We expect that anything that happens with wasi-thread, if turns out to still be necessary at all, will only happen after the core wasm thread spawning proposal has reached some amount of stability.
WebAssembly specification can be a slow process because it takes a lot of work and coordination across many different companies. In particular, Web engines are very conservative in what they ship because once they ship a feature they can never undo it or break it without breaking the Web itself, something they work very hard to never do. But as Yosh says, many of the companies involved have made thread spawning a business priority and are funding experts to work on it, and the Bytecode Alliance is exploring ways to ship thread spawn before Web engines do.
One thing we do need to do better is communicate to the current and potential users of wasi-threads that the proposal shouldn't be expected to make progress until the core spec work has matured, and that users probably don't want to depend on it unless they are prepared to deal with the pain of moving to the new way of doing things once that is figured out.