WIP: `AsyncRuntime` and `AsyncWorker`

[krhougs]

Problems to solve

• Current sync API of Runtime creates a new tokio runtime on each operation, which is wasting resources.
• It's hard to serve background workers since current API is blocking and being impossible to exchange data with on-going function calls
• Missing approachs to integrate with big projects running with a multi-threaded tokio runtime

To-do

• [x] Separate current sync API from new async API by cargo features
• [x] AsyncRuntime: Deno wrapper that works within a single-threaded tokio runtime
• [x] AsyncWorker: Worker that works with its own thread and tokio runtime
• [ ] Handle event loop withinAsyncRuntime to make js async function calls no more blocking current thread to allow concurrent js async function calls
• [x] Migrate the DefaultWorker for AsyncWorker trait to non-blocking async API
• [ ] Migrate the DefaultWorker for SyncWorker trait to work with AsyncRuntime
• [ ] Unit tests
• [ ] Deprecates the sync SyncRuntime(Runtime in current version)

[rscarson]

Thanks for the contribution!

You are correct that creating a new tokio runtime each time is a waste, that's actually fixed in master as of now

What's the advantage of a seperate runtime over the async variants of the existing functions?

[krhougs]

Hi, @rscarson!

What's the advantage of a seperate runtime over the async variants of the existing functions?

Current Runtime with sync API provides an easy way to run any JS async functions in sync programs, it blocks current thread on every operation on the deno runtime until finished or timed out. While it is quite simple and elegant when the program is tiny or the JS code doesn't play too much with IO, it brings limitations:

• The Runtime will always panic if the caller function is already running on a tokio runtime (Worker solves this but there are still problems)
• On common circumstances, the whole program will block to wait for js calls if the calls take too long to finish(even with Worker)
• It's impossible to exchange data and send events between rust code and current running js code
  • Example 1: I'd like to run a JS function to provide background IPC
  • Example 2: I'd like to run a JS function polling for external states and reporting the states to rust code

To solve the problems above:

• AsyncRuntime provides non-blocking APIs that directly works within a tokio CurrentThread runtime (JsRuntime from deno_core is not thread-safe, it panics in tokio MultiThreaded runtimes if you are trying to invoke any Rust closures(e.g. deno_fetch) in JS codes)
• AsyncWorker wraps the AsyncRuntime with a dedicated thread and a dedicated tokio CurrentThread runtime, and provides non-blocking APIs for complex applications running with an existing tokio MultiThreaded runtime.

[rscarson]

Hi, @rscarson!

What's the advantage of a seperate runtime over the async variants of the existing functions?

Current Runtime with sync API provides an easy way to run any JS async functions in sync programs, it blocks current thread on every operation on the deno runtime until finished or timed out. While it is quite simple and elegant when the program is tiny or the JS code doesn't play too much with IO, it brings limitations:

• The Runtime will always panic if the caller function is already running on a tokio runtime (Worker solves this but there are still problems)
• On common circumstances, the whole program will block to wait for js calls if the calls take too long to finish(even with Worker)
• It's impossible to exchange data and send events between rust code and current running js code
  • Example 1: I'd like to run a JS function to provide background IPC
  • Example 2: I'd like to run a JS function polling for external states and reporting the states to rust code

To solve the problems above:

• AsyncRuntime provides non-blocking APIs that directly works within a tokio CurrentThread runtime (JsRuntime from deno_core is not thread-safe, it panics in tokio MultiThreaded runtimes if you are trying to invoke any Rust closures(e.g. deno_fetch) in JS codes)
• AsyncWorker wraps the AsyncRuntime with a dedicated thread and a dedicated tokio CurrentThread runtime, and provides non-blocking APIs for complex applications running with an existing tokio MultiThreaded runtime.

I mean compared to the WIP Async API already present in master

The upcoming 0.5.0 release will have full async support on the existing runtime, and reuse its tokio runtime