[WASM + Winit + Wgpu] Weird error about waiting on the main thread despite not waiting on the main thread

[parasyte]

@Shapur

• I had no idea std::sync::mpsc blocked. I will try your suggestion tomorrow

This might be a bug introduced by the crossbeam-channel change that happened in 1.67.0 ^[1]. The docs for try_recv claims that it "will never block". But it does sometimes:

• try_recv() calls self.read(): rust/library/std/src/sync/mpmc/array.rs,#364
• read() calls self.senders.notify(): rust/library/std/src/sync/mpmc/array.rs,#301
• notify() calls self.inner.lock(): rust/library/std/src/sync/mpmc/waker.rs,#168
  • Blocking occurs under contention, at least on the wasm Mutex implementation.

@Shapur

• Do I understand this correctly: ?
  • Rusts std::sync::atomic types are safe to use on the main thread on wasm
  • They do not block when reading / writing
  • (I assume) They don't use JavaScript Atomics.wait() under the hood, but do something different that doesn't block?

That is my understanding, yes. The types in std::sync::atomics use compiler intrinsics, and there is no "atomic wait" intrinsic.

---

1. There is an open issue on the upstream crossbeam repo: crossbeam::channel::Receiver::try_recv can block forever if sending thread is blocked · Issue #997 · crossbeam-rs/crossbeam (github.com) I added a link back here to that thread. ↩︎