Version
v1.37.0

Target
wasm32-unknown-unknown

Description
In the browser context, in it's main thread, blocking calls cause panic, so it's really not an option to use std::sync::Mutex, or anything that can block the main thread.

I assumed Tokio channels would be fully async and wouldn't use any blocking primitives, but it looks like that's not the case. When I checked it's code, found multiple places blocking can occur, like:

Here is one of the panics I encountered while using tokio channels in the browser:

console.js:36 RuntimeError: Atomics.wait cannot be called in this context
at openmina_node_web.wasm.std::sys::sync::mutex::futex::Mutex::lock_contended::h26da324537dc575a (openmina_node_web_bg.wasm:0x11cd519)
at openmina_node_web.wasm.tokio::runtime::park::wake::h73a00f0ed933a774 (openmina_node_web_bg.wasm:0x11ab2fc)
at openmina_node_web.wasm.tokio::sync::task::atomic_waker::AtomicWaker::wake::h0953ea3f1740360a (openmina_node_web_bg.wasm:0x1219144)
at openmina_node_web.wasm.tokio::sync::mpsc::chan::Tx<T,S>::send::h0b8b79b860905134 (openmina_node_web_bg.wasm:0x109fcb4)

I'm not sure if fixing this is in the scope of this project, but we probably should add to the docs case when those certain calls might panic right?