4 ms·

> This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications. Knowing no

by moss2 4y ago

> This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications. Knowing nothing about WebAssembly, I would guess it's because JS runs on a single thread.

hermanradtke 4y ago
This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html
- koonsolo 4y ago
  On the browser you have Web Workers and Service Workers, both run on separate threads :). https://web.dev/workers-overview/#:~:text=Web%20workers%20and%20service%20workers%20%23&text=Both%20run%20in%20a%20secondary,limited%20access%20to%20browser%20APIs https://web.dev/workers-overview/#:~:text=Web%20workers%20an.... https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
  - kllrnohj 4y ago
    Those are really more like separate processes. There's no ability to do a shared heap in browser JS, meaning it functionally doesn't have threads. Whether or not workers are actually implemented as threads or processes in the runtime is irrelevant. As far as the JS code itself is concerned & what you can do with it, browser JS is lacking multi-threading. There's just no way to do a shared heap, and that is the biggest defining difference between a process and a thread.
    - afavour 4y ago
      The web has SharedArrayBuffer. It’s just difficult to work with.
      - kllrnohj 4y ago
        Creating a shared memory allocation between 2 processes doesn't convert them to threads. The heaps are still distinct.
        azakai 4y ago
        The JavaScript heaps are distinct, that's true, but there is a single shared wasm heap which is used from multiple threads. That is enough to implement the pthreads API. Applications like Photoshop and Google Earth use ptheads on the Web so their compiled C++ is multithreaded, very similar to how it would run natively, and with similar responsiveness and throughput speedups. Though there are some limitations too, see https://emscripten.org/docs/porting/pthreads.html https://emscripten.org/docs/porting/pthreads.html
        flohofwoe 4y ago
        The entire WASM heap is a single ArrayBuffer (or SharedArrayBuffer) object.
        koonsolo 4y ago
        Practically speaking, you just want shared memory in your threads. What would a shared heap offer that shared memory can't?
- mike_hearn 4y ago
  That's not really threading by the definition normally used in other languages. You can't allocate JS objects or structures and read/write them from multiple threads at once. JS is an inherently thread unsafe language and likely always will be.

by moss2 4y ago

hermanradtke 4y ago

This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html

koonsolo 4y ago
On the browser you have Web Workers and Service Workers, both run on separate threads :). https://web.dev/workers-overview/#:~:text=Web%20workers%20and%20service%20workers%20%23&text=Both%20run%20in%20a%20secondary,limited%20access%20to%20browser%20APIs https://web.dev/workers-overview/#:~:text=Web%20workers%20an.... https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
- kllrnohj 4y ago
  Those are really more like separate processes. There's no ability to do a shared heap in browser JS, meaning it functionally doesn't have threads. Whether or not workers are actually implemented as threads or processes in the runtime is irrelevant. As far as the JS code itself is concerned & what you can do with it, browser JS is lacking multi-threading. There's just no way to do a shared heap, and that is the biggest defining difference between a process and a thread.
  - afavour 4y ago
    The web has SharedArrayBuffer. It’s just difficult to work with.
    - kllrnohj 4y ago
      Creating a shared memory allocation between 2 processes doesn't convert them to threads. The heaps are still distinct.
      - azakai 4y ago
        The JavaScript heaps are distinct, that's true, but there is a single shared wasm heap which is used from multiple threads. That is enough to implement the pthreads API. Applications like Photoshop and Google Earth use ptheads on the Web so their compiled C++ is multithreaded, very similar to how it would run natively, and with similar responsiveness and throughput speedups. Though there are some limitations too, see https://emscripten.org/docs/porting/pthreads.html https://emscripten.org/docs/porting/pthreads.html
      - flohofwoe 4y ago
        The entire WASM heap is a single ArrayBuffer (or SharedArrayBuffer) object.
      - koonsolo 4y ago
        Practically speaking, you just want shared memory in your threads. What would a shared heap offer that shared memory can't?
mike_hearn 4y ago
That's not really threading by the definition normally used in other languages. You can't allocate JS objects or structures and read/write them from multiple threads at once. JS is an inherently thread unsafe language and likely always will be.