3 ms·

ECMAScript Shared Memory and Atomics Proposal

26 points by antouank 11y ago

josteink 11y ago
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?
- aardvark179 11y ago
  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.
- chrisseaton 11y ago
  > Though not a part of this specification, we intend for the role of "threads" to be played by Web Workers in web browser environments.
  - TeMPOraL 11y ago
    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"?
    - chrisseaton 11y ago
      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.
aikah 11y ago
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.
- seanmcdirmid 11y ago
  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.
rwlincoln 11y ago
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.

26 points by antouank 11y ago

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?

aardvark179 11y ago
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.
chrisseaton 11y ago
> Though not a part of this specification, we intend for the role of "threads" to be played by Web Workers in web browser environments.
- TeMPOraL 11y ago
  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"?
  - chrisseaton 11y ago
    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.

aikah 11y ago

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.

seanmcdirmid 11y ago
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.

rwlincoln 11y ago

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.