
ECMAScript Shared Memory and Atomics Proposal - antouank
http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html
======
rwlincoln
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.

------
aikah
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
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.

------
josteink
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?

~~~
chrisseaton
> 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
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
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.

