The article title is misleading. Wasm will not support multithreading, rather it'll be multiprocess via web workers and shared arrays for communication. It's not a single address space - code or data.
Multithreading Rust and Wasm
21–30 of 47 posts
Re: Multithreading Rust and Wasm
#22Earlier quoted context omitted.
It's not just because it's shiny. Rust happens to (a) be a great fit for the parts of WebAssembly that have been implemented so far (partly because it doesn't need GC), and (b) have done a really good job of building WebAssembly tooling with nicer ergonomics than other languages.
WASM is the new and shiny also. I'm not even sure what to do with it ATM given that the DOM story still hasn't been figured out.
As a child raised on 80s 8-bit computers, and a fan of emulation, I love what WASM does for in-browser emulators. You can run an enormous amount of Apple II, Commodore 64, etc. software on archive.org, all compiled using emscripten.
Re: Multithreading Rust and Wasm
#23The ultimate test would be to see if it is possible to implement an efficient concurrent GC in Rust+WASM. This might require memory fence instructions in WASM.
Re: Multithreading Rust and Wasm
#24The article title is misleading. Wasm will not support multithreading, rather it'll be multiprocess via web workers and shared arrays for communication. It's not a single address space - code or data.
The threads can all use the same SharedArrayBuffer for their memory, and thus a single address space.
If the SharedArrayBuffer wasn’t shared, what’s the point of the atomic instructions, etc.
Re: Multithreading Rust and Wasm
#25The ultimate test would be to see if it is possible to implement an efficient concurrent GC in Rust+WASM. This might require memory fence instructions in WASM.
I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm.
Hence the GC work to give a higher level API that can more easily be sandboxed.
Re: Multithreading Rust and Wasm
#26The article title is misleading. Wasm will not support multithreading, rather it'll be multiprocess via web workers and shared arrays for communication. It's not a single address space - code or data.
The threads can all use the same SharedArrayBuffer for their memory, and thus a single address space. If the SharedArrayBuffer wasn’t shared, what’s the point of the atomic instructions, etc.
From TFA:
WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Memory backed by a SharedArrayBuffer will refer to the same memory!
Re: Multithreading Rust and Wasm
#27Earlier quoted context omitted.
The threads can all use the same SharedArrayBuffer for their memory, and thus a single address space. If the SharedArrayBuffer wasn’t shared, what’s the point of the atomic instructions, etc.
From TFA: WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Mem…
This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.
Re: Multithreading Rust and Wasm
#28The ultimate test would be to see if it is possible to implement an efficient concurrent GC in Rust+WASM. This might require memory fence instructions in WASM.
I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.
Virtualization technology is quite mature now, and allows running low-level code (that can access the stack) with safety. Servers run this type of code all the time!
Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone?
Also, language designers do not want a GC embedded in their assembly language; they want to implement it themselves, using their own constraints.
Re: Multithreading Rust and Wasm
#29Earlier quoted context omitted.
From TFA: WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Mem…
This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.
And with the current trend of ongoing exploits actually safer than threads.
Re: Multithreading Rust and Wasm
#30Earlier quoted context omitted.
From TFA: WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Mem…
This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.
Nope they are using the same SharedArrayBuffer as their memory object.