5 ms·

I hope they scrap it for a better model. Shared memory + locks is not the only way to handle concurrency and can be difficult to reason about. I don't quite un

by matlin 9y ago

I hope they scrap it for a better model. Shared memory + locks is not the only way to handle concurrency and can be difficult to reason about. I don't quite understand what problem it's solving that message passing doesn't already. Anyone have any insight on this?

white-flame 9y ago
Parallel scanning of large data sets, like object graphs. You don't want to copy the entire graph to each thread, nor do fine grained passing around of a node per traversal. However, if what this exposes is just an array of bytes, that's less useful as you have to cast your own object model on top of it. Large image data might be still useful as just bytes, with threads running convolutions or NNs on it.
fzzzy 9y ago
I think the main use case is to support c++ codebases compiled with emscripten without having to rewrite the whole codebase to not assume shared mutable state.
hajile 9y ago
Fundamentally, you have to implement every other approach using locks behind the scenes (with the possible exception of immutable data). It may not be an idea user primitive, but serves library makers well.
seanmcdirmid 9y ago
Shared memory + locks isn't about concurrency, but probably about parallelism. If you just need concurrency, then messaging between web workers should be good enough.
nteon 9y ago
It isn't the only way to handle concurrency, but they are the only primitives that can be used to port existing code (C/C++/Rust/etc) into the browser sandbox without killing performance, or introducing crazier and unsound primitives (like stack manipulation). I've used SharedArrayBuffers to port things like latex into the browser ( https://browsix.org https://browsix.org ), and without it you can't use wasm or asm.js, you need to interpret C code in JavaScript to save/restore the stack on system calls.
- dragonwriter 9y ago
  > It isn't the only way to handle concurrency, but they are the only primitives that can be used to port existing code (C/C++/Rust/etc) into the browser sandbox without killing performance I thought a big reason why we have WASM is so that that emphatically does not need to be a concern of JS.

by matlin 9y ago

white-flame 9y ago

Parallel scanning of large data sets, like object graphs. You don't want to copy the entire graph to each thread, nor do fine grained passing around of a node per traversal. However, if what this exposes is just an array of bytes, that's less useful as you have to cast your own object model on top of it. Large image data might be still useful as just bytes, with threads running convolutions or NNs on it.

fzzzy 9y ago

I think the main use case is to support c++ codebases compiled with emscripten without having to rewrite the whole codebase to not assume shared mutable state.

hajile 9y ago

Fundamentally, you have to implement every other approach using locks behind the scenes (with the possible exception of immutable data). It may not be an idea user primitive, but serves library makers well.

seanmcdirmid 9y ago

Shared memory + locks isn't about concurrency, but probably about parallelism. If you just need concurrency, then messaging between web workers should be good enough.

nteon 9y ago

It isn't the only way to handle concurrency, but they are the only primitives that can be used to port existing code (C/C++/Rust/etc) into the browser sandbox without killing performance, or introducing crazier and unsound primitives (like stack manipulation). I've used SharedArrayBuffers to port things like latex into the browser ( https://browsix.org https://browsix.org ), and without it you can't use wasm or asm.js, you need to interpret C code in JavaScript to save/restore the stack on system calls.

dragonwriter 9y ago
> It isn't the only way to handle concurrency, but they are the only primitives that can be used to port existing code (C/C++/Rust/etc) into the browser sandbox without killing performance I thought a big reason why we have WASM is so that that emphatically does not need to be a concern of JS.