Are there any other Send + Sync abstractions for JsValue?

[ghost]

I recently wrote JsArc, which is a wrapper around JsValue that is Send + Sync. It accomplishes this by keeping JsValues on one thread (in syntax only) and sending closures from other threads to be executed on it. The purpose for writing it was to more easily pass trait restrictions.

I think it's examples are mostly self explanatory

let v0 = JsArc::new(|| 0.into()).await;
let v1 = JsArc::new(|| 1.into()).await;
let v2 = JsArc::new(|| 2.into()).await;
let v3 = JsArc::new(|| 3.into()).await;
let v4 = JsArc::new(|| 4.into()).await;

let ten = v0
    .with_many(vec![&v1, &v2, &v3, &v4], |mut all| {
        let [v0, v1, v2, v3, v4] = &all[..] else {
            unreachable!("Not possible");
        };

        let result = v0 + v1 + v2 + v3 + v4;

        all.push(result);
        all
    })
    .await; 

JsValues are wrapped with closures, then those wrapped JsValues can be used with each other. It then makes it possible to do the following even though JsValue itself is not Send + Sync

let str: Arc<JsArc> = JsArc::new(|| "hello!".into()).await.arc();

I arrived at writing this type after writing an abstraction for bindings to WalletConnect. When writing those bindings, I needed to implement a trait for a transport that interacted with a JsValue. (And that trait required the type to be Send + Sync). In the library, the type that implemented the trait used a async_channel::Sender which sent messages to runtime/server running in a promise.

Solution: Message passing to runtime/server

A struct with internal JsValues values cannot directly interact with the trait requirements for ethers, alloy, and other providers because they require Send + Sync restrictions. Without an existing runtime, a safe Rust solution is to use message sending with a library like async_channel and a runtime/server to listen for these messages. This is what this crate does, it acts a runtime/server, and providers requests send messages to pass the trait restrictions from the Rust based providers.

The current version to perform a JSON request against the JS binded RPC provider looks something like the following

let request = RequestFromTransport {
    full_rpc_request: json_request,
    queue_type: queue_type,
    send_back_to: send,
    started: false,
    start_time: None,
    queue_time: Utc::now(), 
};

if let Err(_e) = server_cmd_cli
    .send(ClientCommands::RpcRequest(request))
    .await
{
    return Err(WalTransportFailure {
        msg: "Channel closed. This should never happen. Open an issue: {_e:?}".into(),
        failure: WalletConnectTransportFailure::Json(JsonFailure::JsDe),
    });
}

if let Ok(result) = receieve.recv().await {
    result
} else {
    return Err(WalTransportFailure {
        msg: format!("Channel closed. This should never happen. Open an issue"),
        failure: WalletConnectTransportFailure::Json(JsonFailure::JsDe),
    });
}

Which has the associated runtime/server that is spawned to run as a promise in the background

loop {
        let next_cmd = self.command_receiver_channel.recv().await.unwrap();

        match next_cmd {
            ClientCommands::RpcRequest(req) => {
                if self.rpc_runner.has_active_request() {
                    match req.queue_type {
                        QueueTypes::UserKillRequest => {
                            let _ = self.rpc_runner.send_request_kill_signal().await;

                            // User requests can quickly change before being finished. If a user changes
                            // their request, then other user requests should just be cancelled.
                            if let Some(next_kill_req) = &self.active_kill_request_next {
                                let _ = next_kill_req.kill().await;
                            }

                            self.active_kill_request_next = Some(req);
                        }
                        QueueTypes::SystemQueueRequest => {
                            self.rpc_request_queue.push_back(req);
                        }
                    }
                } else {
                    let _ = self.rpc_runner.send_request(req).await;
                }
            }
        /* The rest of the matched types are also included here, but removed in this description */
        }
}

I realized afterwards that the abstraction could likely been less complex with the closure wrapping type

Solution: Using a JsArc to abstractly include a JsValue

After writing all of this, I realized this could have been simplified with a wrapping type that does all of this with closures. So, I took the runtime/server related stuff, and made a custom type, JsArc, that I think would help to reduce the complexity. In the example of RPC requests, the above could have been something like the following

let (s, r) = async_channel::unbounded();
let request: String = request;

self.jswallet.with_self_async(|jswallet| async move {
	let result = jswallet.request(request).await;
	s.send(result.to_string().unwrap()).await;
	
    jswallet
})
.await;

let result: String = r.recv().await;

Though, I didn't fix the bindings abstraction because I had already written message sending and receiving for everything. If I were to write it again, I think I would just use that wrapped JsValue type instead of message passing to a custom runtime/server.

I think the pattern of using message passing to circumvent the trait restrictions has likely been used in other libraries. Are there any other variations of the created type that already exist? Are there any more obvious solutions I should have considered instead?

edit: Sorry for the bump. My account was on a shadow ban and this post disappeared from GitHub. I still want to keep this question open, because I think there are likely better possible versions. (but maybe they'll be written unrelated to WASM)

I also removed the WalletConnect library because I didn't really like it, but I think the discussion is still relevant.

[daxpedda]

If you aren't actually going to deploy this in a multi-threaded enviromment, you might as well make a wrapper that pretends JsValue is Send + Sync. Wgpu did this with their fragile-send-sync-non-atomic-wasm crate feature and Bevy recently did the same.

You can also use #[cfg(target_feature = "atomics")] guards to switch between different implementations.

[ghost]

If you aren't actually going to deploy this in a multi-threaded enviromment, you might as well make a wrapper that pretends JsValue is Send + Sync. Wgpu did this with their fragile-send-sync-non-atomic-wasm crate feature and bevyengine/bevy#12205 recently did the same.

I feel like that's more of a symptom of compounding technical debt than a desirable solution. I don't think there would be overall approval if rust just did this by default as this change causes downstream dependencies to automatically become incompatible with threading.

My first attempt at writing it actually used a static mut and lock, but I changed it because static mut is frequently considered a mistake and even if I did not have aliasing issues, it seemed likely that JsValue's memory model would not be fixed anytime soon to actually make using it seem safe. I guess I like the pretend version that becomes incompatible when atomics are enabled more than the static mut version though.

You can also use #[cfg(target_feature = "atomics")] guards to switch between different implementations.

It then requires maintaining two different versions. I don't view the abstraction as expensive. My opinion is more that JsValues will always be inherently slow, JS wasn't designed for high performance compute.

[daxpedda]

I agree that libraries should account for atomics support instead of pretending it doesn't exist. But not every project is a re-usable library (though the context of OP is).

I think its also important to note that not only is there significant overhead but also a behavioral difference. The solution used in the OP requires a "context switch" to execute. This isn't just measurable overhead, but can introduce unexpected behavior if the user isn't aware that they are yielding to the event loop.

This all has a lot of implications that need to be considered, e.g. it might be problematic if a library behaves different depending on target features.