Optimal way to integrate this crate into a single-threaded async environment?

[lquerel]

I'm exploring the possibility of integrating this crate into a single-threaded async runtime (1 runtime per core). Is there an optimal way to integrate this crate in this kind of context, ideally without Arc, Mutex, RwLock, ...?

[andrieshiemstra]

Hi @lquerel,

This crates start a single thread per runtime (in my own projects I start multiple runtimes so I can balance events to several runtimes)

All things javascript are added to the EventLoop which is consumed by a single thread. Therefore we have little need for Arc or Mutex

Moving variables to the runtime via the JsValueFacade and rt.add_rt_task_to_event_loop is done without mutexes but with channels.

Running rust code code from the runtime runs async tasks in a separate tokio runtime (the TaskManager does that, it should really use the existing tokio runtime if possible)

Whether or not you should run multiple runtimes really depends on what your projects looks like but most likely you can run a single runtime with its single thread and let the rust logic run in tokio.

[lquerel]

I probably need to dive a bit deeper into how QuickJS works to understand better. In my case, I already have an async event loop in my existing program, so I'm wondering whether it makes sense to nest another event loop (quickjs_es_runtime) with its own thread instead of merging them. If QuickJS lets me advance the interpretation of JS code in steps of x microseconds or n "instructions", then I think merging the two event loops would probably be a better approach.

[andrieshiemstra]

In that case you should look at using an instance of quickjsruntimeadapter in your own thread.

You can't really advance for x microseconds/steps but there an interrupt handler but that only enables you to stop execution, not resume it.
Also all async tasks are added to a pending_tasks queue which you can execute per job when you want (rt.has_pending_jobs/rt.run_pending_job).

You will also need to redefine or disable some features like setTimeout which depends on my EventLoop.

Running async rust code will still use the extra tokio runtime, but I've been wanting to fix that, do you use tokio or a different async runtime?

[lquerel]

Thank you for this very useful information. I use Tokio in single-thread mode with a LocalSet (soon LocalRuntime since it will presumably stabilize in the next release).