deno_core manual tick/poll
(Learning the ropes of deno_core)
Two related questions:
- If I create a JsRuntime, and call
- I'd like to have a rust code execute in parallel/collaboration with a single embedded deno runtime. E.g. pure rust code in a secondary thread passes a task to the main thread deno runtime. Both the pure rust and deno run in parallel. The difficulty is then, the rust side, at some point, needs to grab a lock and pause the deno runtime. Meaning the deno tick loop also needs to be grabbing a lock on every tick (or grabbing a lock for a group of ticks for better throughput). After acquiring the lock, the pure rust side would then check the status of tasks in the deno runtime, give deno runtime more things to eval, then release the lock and let it start ticking away again. Aside from the natural difficultly of rust and threading, is this realistic? Or is there some tokio/inter-threading problems missing from my mental model
Two related questions:
- If I create a JsRuntime, and call
poll_event_looppoll_event_loop manually. Do I still fundamentally need tokio to be running?- I'd like to have a rust code execute in parallel/collaboration with a single embedded deno runtime. E.g. pure rust code in a secondary thread passes a task to the main thread deno runtime. Both the pure rust and deno run in parallel. The difficulty is then, the rust side, at some point, needs to grab a lock and pause the deno runtime. Meaning the deno tick loop also needs to be grabbing a lock on every tick (or grabbing a lock for a group of ticks for better throughput). After acquiring the lock, the pure rust side would then check the status of tasks in the deno runtime, give deno runtime more things to eval, then release the lock and let it start ticking away again. Aside from the natural difficultly of rust and threading, is this realistic? Or is there some tokio/inter-threading problems missing from my mental model
