rquickjs in a single-threaded async runtime environment?

[lquerel]

I’m exploring the possibility of integrating rquickjs into a single-threaded async runtime (in fact one runtime per core). The presence of multiple Arc<Mutex<_>> is not ideal in this specific case. Is there anything that would prevent us from having a feature in rquickjs to replace Arc<Mutext<_>> with Rc<RefCell<_>> and to remove the Send+Sync bounds (when this feature is enabled)?

[cheesycod]

I’m exploring the possibility of integrating rquickjs into a single-threaded async runtime (in fact one runtime per core). The presence of multiple Arc<Mutex<_>> is not ideal in this specific case. Is there anything that would prevent us from having a feature in rquickjs to replace Arc<Mutext<_>> with Rc<RefCell<_>> and to remove the Send+Sync bounds (when this feature is enabled)?

After doing a bit of experimenting, I think doing this might be a bit difficult, the mutex here is a async aware mutex etc. A simple refcell probably wouldnt work here as it would error if the runtime used across await points

I could be wrong though as I'm fairly new to rquickjs too.

One possible solution to any deadlock related concerns (although not fully optimal) is to use a tokio spawn_local task and send all rquickjs operations desired through a channel to the task and then poll them to completion using a tokio select and FuturesUnordered

[lquerel]

Generally, Rc<RefCell<_>> is perfectly valid in a single-threaded async runtime context as long as you don't hold a Ref/RefMut across an .await. Moreover, Ref/RefMut are !Send, like tokio::sync::MutexGuard. Since rquickjs already uses tokio::sync::Mutex, I think it should be fine to switch to an Rc<RefCell<_>> in a single-threaded async runtime environment, but maybe there's a subtlety I'm missing (this could be done with a feature).

[Sytten]

My goal down the line is to refactor the runtime to be runnable in a task and all interactions be done via message passing. We should be able to support that use case then a bit bit easier.
Some locks are currently held across await points because we allow multiple people to interact with the C engine instead of just one event loop Rust side.

[Sytten]

My goal down the line is to refactor the runtime to be runnable in a task and all interactions be done via message passing. We should be able to support that use case then a bit bit easier.
Some locks are currently held across await points because we allow multiple people to interact with the C engine instead of just one event loop Rust side.