[jamesfmilne]

The threads can all use the same SharedArrayBuffer for their memory, and thus a single address space.

If the SharedArrayBuffer wasn’t shared, what’s the point of the atomic instructions, etc.

[jamesfmilne]

From TFA:

WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Memory backed by a SharedArrayBuffer will refer to the same memory!

[klarifie]

This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.

[monocasa]

At that point, the distinction between threads and processes gets really muddy even when you're not using wasm. clone(2) is just a superset of fork(2) that lets you decide whether to share memory or not (among other resources).

[namibj]

I still think one could use a stackless clone(2) to get rid of the TLB flush when using threaded open(2). It would need to live without using the stack inside the clone however, and that's rather ugly to program.

[nemaar]

Technically, you are right, but if multiple processes use the same shared memory is there a real, meaningful difference? You can do efficient, parallel computation in a browser, does it really matter how it is executed under the hood?

[pjmlp]

And with the current trend of ongoing exploits actually safer than threads.

[jamesfmilne]

Nope they are using the same SharedArrayBuffer as their memory object.