call async javascript function from rust

[sahandevs]

Hi!

TL;DR: Is it possible to call a javascript async function (or callback/closure) from rust like this: javascript_function.call_async(...).await?

I've an op that takes an async callback:

#[op(v8)]
fn op_call_with_unique_stack(
    scope: &mut deno_core::v8::HandleScope,
    this_arg: deno_core::serde_v8::Value,
    cb: deno_core::serde_v8::Value,
) -> Result<(), AnyError> {
    let cb = cb.to_v8(scope)?;
    if !cb.is_function() {
        bail!("must provide a callback");
    }
    let cb = unsafe { deno_core::v8::Local::<deno_core::v8::Function>::cast(cb) };
    let this_arg = this_arg.to_v8(scope)?;
    cb.call(scope, this_arg, &[]);
    Ok(())
}

cb is an async arrow function. I was wondering if it's possible to do something like cb.call_async(...).await.

The reason why I want this is to use tokio::task_local with it.

[waterbang]

hi!,a little personal opinion.
You may to turn polling on the JavaScript side and ask rust for data every time. Otherwise, if the data pressed by rust to JavaScript is too large, JavaScript may overflow the heap. This concept is called opposite pressure.

[waterbang]

just like:

export function loopRustBuffer() {
  return {
    async next() {
      let buffer = null;
      try {
        buffer = await Deno.core.opAsync("op_rust_to_js_buffer");
        const string = new TextDecoder().decode(new Uint8Array(buffer));
        console.log("rust send message to deno_js:", string);
        return {
          value: string,
          done: false,
        };
      } catch (e) {
        return {
          value: buffer,
          done: true,
        };
      }
    },
    return() {
      /// Here you can manually control the asynchronous iterator to be "aborted" and released
    },
    throw() {
      /// Here you can manually control the asynchronous iterator to be "aborted" and released
    },
  };
}

async *waterOverflow() {
    do {
        const buffer = await loopRustBuffer().next();
        /// Data-based specification to define when to end
        // if (isWaitingData > this.hightWaterMark) {
        //   console.log(
        //     "waterOverflow====>",
        //     isWaitingData,
        //     hightWaterMark
        //   );
        //   break;
        // }
        if (!buffer.done) {
          this.isWaitingData++;
        }
        yield buffer;
        /// Here is the point, use do-while instead of finally, you can avoid stack overflow。
    } while (true);
  }

(async function () {
  for await (let num of waterOverflow()) {
    if (!num.done) {
      console.log("webView.waterOverflow:", num);
    }
  }
})();

This should not be an elegant solution, please add if there are other solutions.

[sahandevs]

Thank you for the answer!
I actually use a similar approach everywhere else (like implementing a stream for fetch) but here because I need to use tokio::task_local it's kinda hard to do that. am I missing something?

[waterbang]

Are you declaring a global static variable?
I'm using ‘lazy_static’，here's what I did：

//cargo.toml
lazy_static = "1.4.0"

// use
use lazy_static::*;
lazy_static! {
    // pub(crate) static ref BUFFER_HANDLER: Mutex<Vec<Vec<u8>>> = Mutex::new(vec![]);
  pub(crate) static ref BUFFER_RESOLVE: Mutex<Vec<Vec<u8>>> = Mutex::new(vec![]);
}

I haven't tried tokio::task_local

[sahandevs]

it's like a global variable for a unique call stack.
Image in the javascript code there is a function called handleRequest(req) which handles HTTP requests.
On the rust side, we start a web server using something like warp or hyper crates. basically receive the request from warp and pass it to the handleRequest(req) by calling it. We need a unique id for each request and we don't want to explicitly pass it down via function parameters like handleRequest(req, request_id). There are some custom implementations of functions like fetch that can call something like getRequestId() without passing anything to it and receiving the request's id.
Basically scoped variables (thread local variables) for async functions.

[waterbang]

Thank you!
I should learn from you to assign an id to each request instead of using the queue directly, thanks for the guide.