Re:Web Assembly and Go: A look to the future
by johncolanduoni on Saturday June 23, 2018 @06:01PM
(#17383688)
Existing JS runtimes actually use shared-memory concurrency a ton, even ignoring the (currently disabled) SharedArrayBuffer. Code generation and garbage collection have at least some concurrent stages on all the major JS engines. JavaScriptCore even exposes this in its API.
Re:Web Assembly and Go: A look to the future
by TekMol on Saturday June 23, 2018 @12:52PM
(#17382085)
Javascript already has multithreading via webworkers. That's not something WASM will introduce.
Re:Web Assembly and Go: A look to the future
by rubber_duck on Saturday June 23, 2018 @01:02PM
(#17382156)
SharedArrayBuffer is only available in chrome and FF and they disable it by default so no way to do standard multithreading via webworkers.
Re:Web Assembly and Go: A look to the future
by TekMol on Saturday June 23, 2018 @01:15PM
(#17382218)
It was disabled because of spectre.
Multithreaded WASM isn't here either.
I think WASM will face the same security considerations.
Re:Web Assembly and Go: A look to the future
by untog on Saturday June 23, 2018 @02:39PM
(#17382689)
Webworkers are multithreading. You just have to use slower, async communication methods. WASM will likely be the same way, given the security considerations.
Re:Web Assembly and Go: A look to the future
by pjmlp on Saturday June 23, 2018 @03:21PM
(#17382896)
WASM will have more low level support.
https://github.com/WebAssembly/threads/blob/master/proposals...
Web Assembly is gimped because it needs to be compatible with existing JS runtimes - when they add threading support you will no longer be able to run a WASM shim in JS but at the same time WASM will become a lot more general purpose.