4 ms·

The article title is misleading. Wasm will not support multithreading, rather it'll be multiprocess via web workers and shared arrays for communication. It's no

The article title is misleading. Wasm will not support multithreading, rather it'll be multiprocess via web workers and shared arrays for communication. It's not a single address space - code or data.

jamesfmilne 8y ago
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 8y ago
  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 8y ago
    This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.
    - pjmlp 8y ago
      And with the current trend of ongoing exploits actually safer than threads.
    - jamesfmilne 8y ago
      Nope they are using the same SharedArrayBuffer as their memory object.
    - nemaar 8y ago
      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?
    - monocasa 8y ago
      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 8y ago
        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.

jamesfmilne 8y ago

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 8y ago
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 8y ago
  This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.
  - pjmlp 8y ago
    And with the current trend of ongoing exploits actually safer than threads.
  - jamesfmilne 8y ago
    Nope they are using the same SharedArrayBuffer as their memory object.
  - nemaar 8y ago
    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?
  - monocasa 8y ago
    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 8y ago
      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.