Futures

[luciusmagn]

Add futures to Rhai (exact design TODO)

[KaiserKarel]

Would something like Engine::register_async_fn be possible? Most futures would probably come from host provided functions, such as interfacing with an http client. Even though the rhai script would still make API calls sequentially, the host is not bogged down by a blocking script. (More relevant if running multiple scripts inside a server for example).

[schungx]

Well, in that case, it would make sense to make the eval methods async as well. You don't do async half-ways...

Register an async function, and if the Engine blocks on the call, then it is essentially blocking the threading running Engine as well. In that case, you gain nothing since you're blocking a thread no matter what.

Better to put the .await inside the function itself and make the function non-aynsc.

[KaiserKarel]

You mean putting the .await in the host function? That would only be allowed if the function is async. Moving back into sync world would require block_on, which puts us back at the start.

I'm not familiar at all with the engine internals, and assumed it runs in the same thread as the host calling eval. register_async_fn would at least allow the server to do something else as the engine would yield.

[schungx]

as the engine would yield.

Exactly. That's the thing. The Engine needs to yield. So something like eval_async.

Might be easy to make such a method, but I'm not quite sure about the way to store an async function pointer and whether it is essentially the same as storing a normal function pointer...

I'm not very familiar with async myself so I don't know how to go there yet...

[KaiserKarel]

I'll have a look at this sometime next week. The register macro is a bit arcane, so will need to do some reading. :)

[xSke]

Would Lua/Wren-style fibers/coroutines work? If you're implementing a language runtime it doesn't require too much plumbing to add, and would probably integrate quite neatly with Rust's existing async system. Your Rhai script could call a http_request() function and that'd yield to Rust, which at some point would yield control back to the Rhai engine when the request is done, "blocking" the Rhai code from proceeding without actually blocking any threads. Could even make the Rust-side function callbacks async themselves, and just have code execution continue once the future completes with its result?

[schungx]

In such a case, the Rhai script would be blocking, but the Engine will be async such that it doesn't occupy a thread until someone (the application) yields a value back to it. How to do that and how to make the application aware that the Engine is waiting for something (and yielding the correct value back) is going to be tricky. I'll have to research on this some more, as I haven't written a lot of async Rust yet to be very proficient in it...

[xSke]

Wonder if you could literally just... have a register_async_fn taking a function returning a impl Future<Output=Result<T, EvalAltResult>>. Add an async variant of the eval functions and just await those callbacks when the interpreter hits them - the Engine itself and the code inside it would be "single-threaded" and "blocking" but not with respect to the program as a whole, as it would just defer to Rust's task scheduler. This would require "async-ifying" the entire interpreter, at least up to the point where registered functions are executed, but could be hidden behind a feature flag or otherwise refactored to make less big a deal, somehow.

[schungx]

Instead, how about eval_async that'll wait for the async function to finish?

I'm not sure if that requires Engine to be Pin-able or something...

[KaiserKarel]

I don't think we'd have to change to much about the Engine internals. Pin is only required if we're implementing the future trait by hand, which we are not. Storing impl Future<Output=Result<T, EvalAltResult>> should do the trick.

[schungx]

I have given it some more thoughts. It is not as easy as it sounds...

1. register_async_fn for functions returning Future<Output=Result<Dynamic, Box<EvalAltResult>>>
2. Since function calls can now be async, eval_stmt and eval_expr need to be async.
3. The entire evaluation stack needs to be async from top to bottom.
4. There is no way to detect whether a script calls an async function (remember eval), so all eval's now need to be async, essentially making Rhai async.
5. Engine::eval would call block_on with eval_async to run a script.

It is not particularly difficult per se, but it requires a change of operation mode for the entire library. I am not sure whether making Rhai async will make normal usage much slower...

If we compile Rhai into byte-codes, however, this suddenly becomes much simpler. That's because a byte-code interpreter is basically one giant match statement plus a loop. That function can be made async (possibly behind a feature gate) and Bob's our uncle.

[0x8f701]

@schungx

5. you can make async executor as a field of Engine then just spawn tasks, that'll remove the overhead of block_on which basically is heavy because it needs to spawn threads.

BTW, actix actor library can wait a future synchronously, basically its context is a mini executor, I think you can see how it implements this.

Eventually I think the following can be interesting, not sure if it's ok for rhai

  engine.register_fn(
            "async_call",
            move |arg1: ImmutableString, ctx: rhai::Context| {
                // wait on a future return Future::Output
                ctx.wait(reqwest::get(&arg1).send()) 
            },
        );

engine.eval_with_scope("let dom = async_call('https://rust.org');")

Ref:
https://github.com/actix/actix/blob/master/src/contextimpl.rs
https://docs.rs/actix/0.10.0-alpha.3/actix/trait.AsyncContext.html#tymethod.wait

[schungx]

That would make the function call blocking... so it is still blocking within the Engine itself.

The idea of this issue is to make the Engine yield, meaning that it can register a function that returns a future, and will yield out to the calling environment once it hits that function call, to be resumed later on when the future resolves. But that means storing all the states plus stack of the evaluation up to that point - this will be much easier with a byte-codes system.

So technically speaking you can do:

fn async do_work() -> i64 {
    engine.eval::<i64>("http.call(url)").await?
}

[0x8f701]

@schungx

I think the importance is

when we call ctx.wait it spawn task immediately for handling this future. If this is done, it's non-blocking. The only blocking code is just waiting for a response

we can also have spawn to not wait for response but it's a little bit useless

  engine.register_fn(
            "async_call",
            move |arg1: ImmutableString, ctx: rhai::Context| {
                // wait on a future return Future::Output
                ctx.spawn(reqwest::get(&arg1).send())  //just spawn task without waiting for response
            },
        );

engine.eval_with_scope("let dom = async_call('https://rust.org');")