3 ms·

Threading support is already implemented in some browsers and well on its way to standardization https://webassembly.org/roadmap/ https://webassembly.org/roadma

Threading support is already implemented in some browsers and well on its way to standardization https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ Should address that concern. However there is another way of looking at performance and is in the context of serverless where typically single threaded performance is inportant, as well as cold start time etc and that’s why Wasm is popular in that scenario

paulgb 4y ago
“Threading support” in this sense is a bit of a misnomer, it’s really support for thread-safe memory constructs. Creating threads is left up to the runtime. On the web, this is done with WebWorkers, but on the server side I don’t think there is yet a standard way to do it supported by major runtimes.
- melony 4y ago
  No shared memory options?
  - paulgb 4y ago
    There is a SharedMemoryBuffer, but it’s a web platform thing, not available in out-of-browser runtimes like wasmtime or wasmer or wasmedge (which Docker uses).
- kllrnohj 4y ago
  > Creating threads is left up to the runtime. On the web, this is done with WebWorkers WebWorkers don't give you multi-threading behaviors (heaps/address spaces are not shared). WebWorkers would be how you launch a new process, but there's still otherwise no way to make a thread (nor even a fork() equivalent for that matter).
  - paulgb 4y ago
    I think you could share an address space by using the same SharedArrayBuffer to back the linear memory of both? I could be wrong here, I haven’t done it, but I thought this was the reason for supporting atomics in the first place. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - kllrnohj 4y ago
      That only shares one allocation (like shared memory does in regular multi-process scenarios), but you still can't share the address space or even any object heaps at all. Like it's not possible to allocate javascript objects out of a SharedArrayBuffer such that you could pretend you had a shared address space by sticking everything in that. As in, SharedArrayBuffer is equivalent to shm_open. Which means it's not even that good as a shared memory construct as it's missing all the protection enforcement of memfd (or Android's ashmem)
      - circuit10 4y ago
        WASM stores everything in an array buffer, it doesn't use JavaScript objects because it's not JavaScript (though there are starting to be features that allow it to interoperate with JS objects). If it didn't store everything in a big memory array then it wouldn't really work because C assumes that And no, WASM doesn't support memory protection
      - monocasa 4y ago
        But shared array buffer is the underlying primitive generally for webassembly accessible memory.
- ridruejo 4y ago
  Support on the server side is planned, still waiting for standardization https://github.com/bytecodealliance/wasmtime/issues/888 https://github.com/bytecodealliance/wasmtime/issues/888

paulgb 4y ago

“Threading support” in this sense is a bit of a misnomer, it’s really support for thread-safe memory constructs. Creating threads is left up to the runtime. On the web, this is done with WebWorkers, but on the server side I don’t think there is yet a standard way to do it supported by major runtimes.

melony 4y ago
No shared memory options?
- paulgb 4y ago
  There is a SharedMemoryBuffer, but it’s a web platform thing, not available in out-of-browser runtimes like wasmtime or wasmer or wasmedge (which Docker uses).
kllrnohj 4y ago
> Creating threads is left up to the runtime. On the web, this is done with WebWorkers WebWorkers don't give you multi-threading behaviors (heaps/address spaces are not shared). WebWorkers would be how you launch a new process, but there's still otherwise no way to make a thread (nor even a fork() equivalent for that matter).
- paulgb 4y ago
  I think you could share an address space by using the same SharedArrayBuffer to back the linear memory of both? I could be wrong here, I haven’t done it, but I thought this was the reason for supporting atomics in the first place. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - kllrnohj 4y ago
    That only shares one allocation (like shared memory does in regular multi-process scenarios), but you still can't share the address space or even any object heaps at all. Like it's not possible to allocate javascript objects out of a SharedArrayBuffer such that you could pretend you had a shared address space by sticking everything in that. As in, SharedArrayBuffer is equivalent to shm_open. Which means it's not even that good as a shared memory construct as it's missing all the protection enforcement of memfd (or Android's ashmem)
    - circuit10 4y ago
      WASM stores everything in an array buffer, it doesn't use JavaScript objects because it's not JavaScript (though there are starting to be features that allow it to interoperate with JS objects). If it didn't store everything in a big memory array then it wouldn't really work because C assumes that And no, WASM doesn't support memory protection
    - monocasa 4y ago
      But shared array buffer is the underlying primitive generally for webassembly accessible memory.
ridruejo 4y ago
Support on the server side is planned, still waiting for standardization https://github.com/bytecodealliance/wasmtime/issues/888 https://github.com/bytecodealliance/wasmtime/issues/888