rscarson
Accept tokio runtime handle instead of the full runtime?
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
For apps that use tokio outside of executing JS code, having to maintain a reference to the original tokio runtime is cumbersome. It makes it impossible to use the #[tokio::main] macro, and you have to store the Rc<Runtime> somewhere and pass it down to where your rustyscript::Runtime is created.
Additionally, the requirement of Rc instead of Arc means the rustyscript runtime has to be created on the same thread that the runtime was originally created on. I'm not sure if this is intentional because it's a hard requirement, but it means I can't push my entire JS runtime into a background thread (unless I'm missing something).
Describe the solution you'd like A clear and concise description of what you want to happen.
Would it be possible to have rustyscript accept a tokio Handle instead of the runtime itself? The handle can be used to spawn tasks, and is easily accessible anywhere with Handle::current.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
As far as I can tell, there's no alternative to passing the runtime around right now.
Additional context Add any other context or screenshots about the feature request here.
My app needs to load a JS file at initialization, then periodically execute some async code from it. My goal architecturally is to run the JS runtime in a background thread and push messages via an mpsc to it to initiate code execution, then get responses back on another channel. I'm not sure if that is possible given the current tokio runtime requirements.
For apps that use tokio outside of executing JS code, having to maintain a reference to the original tokio runtime is cumbersome. It makes it impossible to use the #[tokio::main] macro, and you have to store the Rc<Runtime> somewhere and pass it down to where your rustyscript::Runtime is created.
That's a solid point. I will explore alternative possibilities
Additionally, the requirement of Rc instead of Arc means the rustyscript runtime has to be created on the same thread that the runtime was originally created on. I'm not sure if this is intentional because it's a hard requirement, but it means I can't push my entire JS runtime into a background thread (unless I'm missing something).
The JS runtime can absolutely never be moved between threads - the underlying v8 instance would become very grumpy
My app needs to load a JS file at initialization, then periodically execute some async code from it. My goal architecturally is to run the JS runtime in a background thread and push messages via an mpsc to it to initiate code execution, then get responses back on another channel. I'm not sure if that is possible given the current tokio runtime requirements.
There are a few pieces of the book that may help you there;
- https://rscarson.github.io/rustyscript-book/advanced/multithreading.html
- https://rscarson.github.io/rustyscript-book/advanced/asynchronous_javascript.html
Fixed in master, will leave this open this the next version publishes.
Runtime now has with_tokio_runtime_handle, which can be used with tokio::main