4 ms·

WebAssembly "threads" depend on SharedArrayBuffer, which is not available on Safari. Whatever your opinion of Apple or web feature adoption in Safari, this defi

WebAssembly "threads" depend on SharedArrayBuffer, which is not available on Safari. Whatever your opinion of Apple or web feature adoption in Safari, this definitely puts a damper on things if you need to support mobile browsers.

jbk 5y ago
Even on the beta of the next Safari?
- orbz 5y ago
  According to https://caniuse.com/sharedarraybuffer https://caniuse.com/sharedarraybuffer it's default disabled on Safari due to spectre/meltdown, but can be enabled.
  - paulgb 5y ago
    In addition to SharedArrayBuffer, it looks like the atomics themselves are in-progress on Safari[1]. They don't work for me on Safari Technology Preview, FWIW. As far as I can tell, “threads” from a WebAssembly implementation's perspective is just the combination of SharedArrayBuffer and atomics; support for the actual threading comes from Web Workers which are already a separate standard. Compilers like Emscripten then use the combination of the three to implement threading. [1] https://webassembly.org/roadmap/ https://webassembly.org/roadmap/
    - jlongster 5y ago
      What doesn't work about them? I use `Atomics.wait` and `Atomics.compareExchange` and maybe a couple other APIs and it works well on Safari Technology Preview (if you enable SharedArrayBuffer).
      - paulgb 5y ago
        Ah, I should have clarified that I mean the assembly instructions for atomics, rather than the JavaScript API. I.e. the opcodes listed here: https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#atomic-memory-accesses https://github.com/WebAssembly/threads/blob/master/proposals...
        jlongster 5y ago
        Oh right, that makes sense in the context of this thread :)
    - RReverser 5y ago
      > As far as I can tell, “threads” from a WebAssembly implementation's perspective is just the combination of SharedArrayBuffer and atomics; FWIW that's exactly what the linked post describes :)
- nightpool 5y ago
  SharedArrayBuffer was disabled in Safari 11 due to Spectre and Meltdown vulnerabilities. https://bugs.webkit.org/show_bug.cgi?id=212069 https://bugs.webkit.org/show_bug.cgi?id=212069 re-enabled it behind a flag, and talks about making it public "Once cross-origin isolation is done". However, it links to https://bugs.webkit.org/show_bug.cgi?id=215407 https://bugs.webkit.org/show_bug.cgi?id=215407 as representing when cross-origin isolation is complete, which as I understand it hasn't seen any activity in the past year.
- turnsout 5y ago
  As far as I can tell, it's not enabled in the beta, but looks like it's available on the Safari Technical Preview on the Mac behind a flag: https://developer.apple.com/safari/technology-preview/release-notes/ https://developer.apple.com/safari/technology-preview/releas...
nextaccountic 5y ago
Web workers already exist and there's wasm threading libraries that target just web workers. https://github.com/w3reality/wasm-mt https://github.com/w3reality/wasm-mt It's just that with sharedarraybuffers and atomics we unlock better performance and can match APIs of native OSes. But that's okay, we can still have a fallback for Safari (specially if we can architect the app so the threads only communicate by passing messages) and it shouldn't be a big deal.
- turnsout 5y ago
  Yes, I've been using WebWorkers for 10 years. My note was intended to give folks a heads-up before they go rewriting their web app in C++ or Rust to take advantage of concurrency via SharedArrayBuffer.

jbk 5y ago

Even on the beta of the next Safari?

orbz 5y ago
According to https://caniuse.com/sharedarraybuffer https://caniuse.com/sharedarraybuffer it's default disabled on Safari due to spectre/meltdown, but can be enabled.
- paulgb 5y ago
  In addition to SharedArrayBuffer, it looks like the atomics themselves are in-progress on Safari[1]. They don't work for me on Safari Technology Preview, FWIW. As far as I can tell, “threads” from a WebAssembly implementation's perspective is just the combination of SharedArrayBuffer and atomics; support for the actual threading comes from Web Workers which are already a separate standard. Compilers like Emscripten then use the combination of the three to implement threading. [1] https://webassembly.org/roadmap/ https://webassembly.org/roadmap/
  - jlongster 5y ago
    What doesn't work about them? I use `Atomics.wait` and `Atomics.compareExchange` and maybe a couple other APIs and it works well on Safari Technology Preview (if you enable SharedArrayBuffer).
    - paulgb 5y ago
      Ah, I should have clarified that I mean the assembly instructions for atomics, rather than the JavaScript API. I.e. the opcodes listed here: https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#atomic-memory-accesses https://github.com/WebAssembly/threads/blob/master/proposals...
      - jlongster 5y ago
        Oh right, that makes sense in the context of this thread :)
  - RReverser 5y ago
    > As far as I can tell, “threads” from a WebAssembly implementation's perspective is just the combination of SharedArrayBuffer and atomics; FWIW that's exactly what the linked post describes :)
nightpool 5y ago
SharedArrayBuffer was disabled in Safari 11 due to Spectre and Meltdown vulnerabilities. https://bugs.webkit.org/show_bug.cgi?id=212069 https://bugs.webkit.org/show_bug.cgi?id=212069 re-enabled it behind a flag, and talks about making it public "Once cross-origin isolation is done". However, it links to https://bugs.webkit.org/show_bug.cgi?id=215407 https://bugs.webkit.org/show_bug.cgi?id=215407 as representing when cross-origin isolation is complete, which as I understand it hasn't seen any activity in the past year.
turnsout 5y ago
As far as I can tell, it's not enabled in the beta, but looks like it's available on the Safari Technical Preview on the Mac behind a flag: https://developer.apple.com/safari/technology-preview/release-notes/ https://developer.apple.com/safari/technology-preview/releas...

nextaccountic 5y ago

Web workers already exist and there's wasm threading libraries that target just web workers. https://github.com/w3reality/wasm-mt https://github.com/w3reality/wasm-mt It's just that with sharedarraybuffers and atomics we unlock better performance and can match APIs of native OSes. But that's okay, we can still have a fallback for Safari (specially if we can architect the app so the threads only communicate by passing messages) and it shouldn't be a big deal.

turnsout 5y ago
Yes, I've been using WebWorkers for 10 years. My note was intended to give folks a heads-up before they go rewriting their web app in C++ or Rust to take advantage of concurrency via SharedArrayBuffer.