Existing WebAssembly threads proposal focuses on enabling wasm compiled program to utilize multiple system threads. This is an extremely useful feature for CPU intensive tasks. But there is a large class of problems which is IO intensive and is better solved by much lighter weight coroutines than system threads. The recent addition of Rust async-wait to a language that already supports multithreading is a good example of such a need. The problem with async-await is that it requires a completely different way to write application code as well as different compilation techniques. From the other side, one of the major reasons for the Go popularity is goroutines which look like real threads to the developer while executed as coroutines by the runtime.
I believe that WebAssembly is uniquely positioned to bring the advantage of Go threading model to practically any multithreaded application that can be compiled to wasm. The idea is that the compiled program doesn’t need to change to leverage the green threads, this becomes the host choice on how to execute it.
Another important feature of WebAssembly is deterministic execution. With green threads it should be straightforward to implement deterministic execution mode for multithreaded targets.
The strawman name for the feature is _Wasmroutines_.
I found a few issues related to "native wasm threads" like https://github.com/WebAssembly/design/issues/126 and https://github.com/WebAssembly/design/issues/1252 but it looks like they are considered as something that wasm might get eventually, but pretty theoretical at this point.
I believe that the _single system thread implementation_ can be done with relatively small effort (for example it could use the normal linear memory) and would provide a lot of value (like executing any multithreaded program without modification) that is worth having as a separate design proposal.
mfateev
All 5 comments
You may be interested in Asyncify, which is a code transformation tool that can be used to pause and resume execution or switch stacks in WebAssembly without requiring any new WebAssembly features. This solution has overhead, and I believe there are plans to propose a new mechanism for stack switching using algebraic effect handlers, which are essentially just resumable exceptions. The exceptions proposal has been designed with this future direction in mind.
tlively
on 2 Jan 2020
Thanks @tlively. Asyncify looks like cool stopgap solution for my problem. I'll try to prototype on top of it. Ideally I would like to execute any multithreaded WebAssembly program without any modification using only the features that the host provides.
mfateev
on 2 Jan 2020
@mfateev I think you're right; there would be significant value in supporting coroutines. There've already been some preliminary discussions about unifying exception handling and coroutines within the framework of algebraic effects. This is discussed in the old exception handling proposal, and I think @rossberg has some newer design thinking compatible with the new exception handling proposal.
lukewagner
on 3 Jan 2020
There is a video where @rossberg presents proposed design for continuations (mentioned by @lukewagner).
chicoxyzzy
on 4 Jan 2020
Thanks for the video. The "stack switching" is a very powerful abstraction that would enable the large number of use cases. Looking forward for it being supported.
My angle is somehow different in proposing no new features in the wasm bytecode. I'm looking into providing the deterministic execution for any multithreaded code that uses atomic.wait/notify and other atomic operations. I believe that we can specify a special host execution mode that is essentially coroutine based, but looks like multhreaded runtime to a Web Assembly application.
mfateev
on 6 Jan 2020
Related issues
ghost
·
7Comments
nikhedonia
·
7Comments
dpw
·
3Comments
aaabbbcccddd00001111
·
3Comments
arunetm
·
7Comments
Most helpful comment
There is a video where @rossberg presents proposed design for continuations (mentioned by @lukewagner).
https://youtu.be/pq-Pa2Fj4nE?t=3231