> However, the shared data block referenced by the two SharedArrayBuffer objects is the same data block, and a side effect to the block in one agent will eventually become visible in the other agent.
This gives you shared memory between two threads. Sure the entire address space isn't shared but I find it hard to deny that this is threading.
> This gives you shared memory between two threads.
This is the key point you're missing. It's not "two threads". It's to different isolated tasks/processes.
Shared array buffers are quite literally what memory-mapped files have been used for over 40 years [1]
=== start quote ===
Another common use for memory-mapped files is to share memory between multiple processes. In modern protected mode operating systems, processes are generally not permitted to access memory space that is allocated for use by another process... There are a number of techniques available to safely share memory, and memory-mapped file I/O is one of the most popular. Two or more applications can simultaneously map a single physical file into memory and access this memory.
=== end quote ===
That's all there is: two separate, isolated processes accessing the same memory. This doesn't make Javascript multithreaded in any way, shape, or form. Browsers give you a rather awkward way to run a separate tasks in Javascript and give you message-passing and shared memory as a way to communicate between them.
Had browsers been able to run other languages than Javascript, you would be able to run one worker in Javascript, and another in SadlyNonExistentScript, and literally nothing would change: you would still have the same postMessage and SharedArrayBuffer as APIs provided by the host.
To run workers isolated from each other when Javascript doesn’t support multithreading, worker threads use a special mechanism.
We all know Node runs on top of Chrome’s V8 engine. V8 supports the creation of isolated V8 runtimes. These isolated instances, known as V8 Isolate , have their own Javascript heaps and micro-task queues.
Worker threads are run on these isolated V8 engines, each worker having its own V8 engine and event queue. In other words, when workers are active, a Node application has multiple Node instances running in the same process.
> However, the shared data block referenced by the two SharedArrayBuffer objects is the same data block, and a side effect to the block in one agent will eventually become visible in the other agent.
This gives you shared memory between two threads. Sure the entire address space isn't shared but I find it hard to deny that this is threading.