ECMAScript Shared Memory and Atomics Proposal | Hacker News Reader

ECMAScript Shared Memory and Atomics Proposal

lars-t-hansen.github.io

26 pointsantouank8 comments

Shouldn't this be a WebAssembly (WASM) only feature? It seems a shame to be introducing the potential for race conditions in JavaScript. Compiling languages that support multiple threads into JS seems to be what is motivating this work.

Just an innocent question , does it really need to be in the spec ? I mean typed arrays make sense, but isn't that too low level ? Things like that, just like async or even promises concern me. Javascript, the language, shouldn't be concerned with async programming at its core. What I mean is, a js environment that support threads directly, doesn't need promises or async stuffs. Isn't putting memory management or concurrency into the spec limiting JS environments to a certain model of memory management or conccurency model ? there is no notion of event loop up until ES6 in the spec.

If you want different implementations to be compatible, they have to be in the spec, especially for something like this! Loops have clearly defined semantics that can be expressed with plain old code, so aren't going to cause compatibility problems.

This does look interesting, and from skimming it this seems to be about introducing the same sort of atomic primitives as found in clojure, ie. Atoms. And as far as I know they were introduced to address the problem of shared, mutable state in a concurrent environment.

If Javascript doesn't have "real" threads, just unordered, asynchronous execution, what need do we have for atoms? You won't be having concurrent access to the shared, mutable state anyway.

Am I missing something?

> Though not a part of this specification, we intend for the role of "threads" to be played by Web Workers in web browser environments.

Which reminds me - and sorry for going slightly off-topic - why on Earth does the JS world invent so many new names for things that already have perfectly good ones? For instance, why "Web Workers" instead of "threads"?

Because with threads you expect shared memory. Web workers currently communicate only by message passing, more like a basic UNIX process. But they're unlike a UNIX process in other ways.

If they used an existing name someone else would be on here complaining about that.

SharedTypedArrays, though whether this should be specified at the JS or WaASM level I'm not sure. What it lacks at this point is a defined memory model but they do seem to note they may want to add fences & so forth.

Reply on news.ycombinator.com