Edit: just check this tutorial. I'd venture to guess to 99% of JS developers it sounds totally bizarre: https://github.com/tc39/ecmascript_sharedmem/blob/master/TUT...
Think of C++ for example. It's used to implement frameworks like JUCE, used for high-level application logic and UIs, but underneath that there are a lot of optimised abstractions. Some of these abstractions can only be so good or so deep until the language they are implemented in can get closer to the "metal" (or in this instance, VM).
I for one welcome these new additions to the ECMAscript spec.
One of those is not like the others.
Clearly the Java language -> Java bytecode -> Java Hardware chain is inherently more native and consistent than C language -> C Virtual Machine -> x64 -> Intel Core 2, where each step in the C language chain looses access to features of the underlying layer.
- Introduce real native types, not complex-named functions that are way more bothersome to work with than types.
- Use WASM or something similar to provide for a low level variant.
Plus, web assembly is here.
> Provide low-level buildings blocks for pthreads-style shared memory: shared memory between threads, atomics and futexes (or synchronic).
New atomic memory operators, including loads/stores annotated with their atomic ordering property, will follow the C++11 memory model, similarly to the PNaCl atomic support and the SharedArrayBuffer proposal. Regular loads and stores will be bound by a happens-before relationship to atomic operators in the same thread of execution, which themselves synchronize-with atomics in other threads. Following these rules, regular load/store operators can still be elided, duplicated, and split up. This guarantees that data-race free code executes as if it were sequentially consistent. Even when there are data races, WebAssembly will ensure that the nondeterminism remains limited and local.
import ctypes
from multiprocessing import Array
mysharedarray = Array(ctypes.<type>, 100)