Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

RuntimeError: Atomics.wait cannot be called in this context

See original GitHub issue

For some reason, initThreadPool seems to be giving this error. I am using the no-bundler feature with a simple go server.

Uncaught (in promise) RuntimeError: Atomics.wait cannot be called in this context
    at core::core_arch::wasm32::atomic::memory_atomic_wait32::h9a9a231b6412c421 (linalg_bg.wasm:0x94e305)
    at std::sys::wasm::mutex::Mutex::lock::h0477dcfe8d39c9ec (linalg_bg.wasm:0x717f9f)
    at std::sys_common::mutex::MovableMutex::raw_lock::h74885940bb867605 (linalg_bg.wasm:0x94bd5d)
    at std::sync::mutex::Mutex<T>::lock::hdd7beaa199985733 (linalg_bg.wasm:0x933c13)
    at spmc::channel::Sender<T>::send::h99ef43bb4692506c (linalg_bg.wasm:0x238560)
    at wasm_bindgen_rayon::wbg_rayon_PoolBuilder::build::{{closure}}::hdce48bcd346070a5 (linalg_bg.wasm:0x613768)
    at <rayon_core::registry::CustomSpawn<F> as rayon_core::registry::ThreadSpawn>::spawn::h986960739e3987c9 (linalg_bg.wasm:0x4eb03d)
    at rayon_core::registry::Registry::new::h28bbaa87b0a093f6 (linalg_bg.wasm:0x8221a)
    at rayon_core::registry::init_global_registry::{{closure}}::hfde6a4e256abdcae (linalg_bg.wasm:0x68e9a8)
    at rayon_core::registry::set_global_registry::{{closure}}::hd1d3fb73eb496efa (linalg_bg.wasm:0x584915)

Here’s the html.

<!DOCTYPE html>
<html lang="en">

<head>
  <title>linalg demo</title>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
</head>

<body>
  <script type="module">
    import init, {initThreadPool} from './../pkg/linalg.js';

    (async () => {
      await init();
      await initThreadPool(navigator.hardwareConcurrency);
    })()
  </script>
</body>

</html>

And here’s my server

package main

import (
	"fmt"
	"net/http"
)

func addHeaders(handler http.Handler) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Cross-Origin-Opener-Policy", "same-origin")
		w.Header().Set("Cross-Origin-Embedder-Policy", "require-corp")

		handler.ServeHTTP(w, r)
	}
}

func main() {
	fsHandler := http.FileServer(http.Dir("./"))
	http.Handle("/", addHeaders(fsHandler))

	fmt.Println("🚀 Listening on http://localhost:5000/")
	http.ListenAndServe(":5000", nil)
}

I also tried it with vite and without the no-bundler feature and getting the same error. Is there some configuration for wasm-bindgen, wasm-pack and wasm-bidngen-rayon that just works?

Issue Analytics

State:
Created 2 years ago
Comments:8

Top GitHub Comments

1reaction

RReversercommented, Nov 4, 2021

Glad to hear! Be sure to watch out for lack of module Workers support in Firefox if you use no-bundler mode (in that case, you need to include polyfill): https://github.com/GoogleChromeLabs/wasm-bindgen-rayon#usage-without-bundlers

0reactions

RReversercommented, Nov 4, 2021

Right, the wording there could certainly be improved. It’s hard to convey difference between “main thread” as in “main thread from PoV of Rust code” vs “main thread” as in “browser main thread used for UI work”.

Btw, I’m serious - I don’t want others to stumble upon this like you did. If you have ideas on how to improve the wording so that it’s clearer, I’m happy to accept PRs 😃