Executing futures in wasm

[richard-uk1]

the wasm-bindgen-futures crate provides for consuming promises as futures, and returning futures to JS as promises, but not executing futures in wasm.

I'm currently experimenting with borrowing the strategy for passing futures to js for my use-case.

[alexcrichton]

I'm not sure it's actually possible to execute futures in wasm without the support of JS? Executing futures involves some degree of blocking but JS/wasm can't block right now I think? Do you have a particular API in mind though for this?

[richard-uk1]

I'm playing with creating an indexeddb library. Eventually, I'd like to make it integrate into a virtual DOM library so an action like a click is processed into an immediate DOM update (loading), and a delayed DOM update (once the promises have resolved).

+------------+     +------------+
|click action+----->future chain|
+-----+------+     +-----+------+
      | pending          |
      |                  | future chain is complete
+-----v------+           |
|state change<-----------+
+------------+

You should be able to get this behavior by specifying your state, and functions describing how the state changes when the future is ready or rejected. This applies equally to fetch as much as indexedDB. The beauty of futures is that you can have quite a complex operation with many steps but treat it as a single atomic operation.

I'm just struggling to get my head around how js and wasm interact here. Do we need an executor in wasm using something like setTimeout(() => {..}, 0), or can we arrange to be woken up by the JS when a promise completes.

I always find the lack of determinism in js a bit frustrating (w.r.t. the order that things will happen in), and I feel like futures would help me get a handle on it, but the big picture is just eluding me.

[richard-uk1]

I'm thinking I probably have to pass the function I want to run into the promise, so that JS knows what code to run. Maybe this means I can't use futures (at least not the standard rust ones).

[richard-uk1]

An example of the code I'd like to be able to write: (pseudo code)

#[derive(Default, Debug, ...)]
struct State {
   name: Option<String>,
   age: Option<u32>,
   loading: bool,
}

enum Action {
   LoadData,
   LoadFailed { reason: String },
   LoadSucceeded {
      name: String,
      age: u32
   }
}

fn merge(action: Action, state: &mut State) {
   match action {
      Action::LoadData => {
         state.loading = true;
      }
      Action::LoadFailed { reason } => {
         eprintln!("loading failed: {}", reason);
      }
      Action::LoadSucceeded { name, age } => {
         state.name = Some(name);
         state.age = Some(age);
         state.loading = false;
      }
   }
}

fn on_click() {
    state.merge(Action::LoadData);
    indexeddb::open("my_db", 1)
        .then(|db| db.start_transaction())
        .then(|(db, trans)| db.object_store("people"))
        .then(|store| store.get(0))
        .then(|record| {
            state.merge(Action::LoadSucceeded {
                name: record.name,
                age: record.age
            });
        }); // todo pass this future somewhere so it gets run.
}

[Pauan]

The way that this is handled in stdweb is that it provides a spawn_local function, which lets you spawn a Future:

spawn_local(some_rust_future);

You can then write your code like this:

fn on_click() {
    state.merge(Action::LoadData);
    spawn_local(indexeddb::open("my_db", 1)
        .then(|db| db.start_transaction())
        .then(|(db, trans)| db.object_store("people"))
        .then(|store| store.get(0))
        .then(|record| {
            state.merge(Action::LoadSucceeded {
                name: record.name,
                age: record.age
            });
        }));
}

Or even easier with async/await!:

fn on_click() {
    state.merge(Action::LoadData);
    spawn_local(async {
        let db = await!(indexeddb::open("my_db", 1))?;
        let trans = await!(db.start_transaction())?;
        let store = await!(db.object_store("people"))?;
        let record = await!(store.get(0))?;
        state.merge(Action::LoadSucceeded {
            name: record.name,
            age: record.age
        });
    });
}

Internally spawn_local uses a Rust dequeue of Tasks, and it uses JavaScript's microtask queue to delay the Future execution by one tick.

The same sort of function should be implementable in wasm-bindgen as well.

[richard-uk1]

@Pauan do you have to be running an event loop for that to work?

[Pauan]

@derekdreery In asynchronous code, an event queue is mandatory (though it's hidden from the user).

JavaScript provides two built-in event queues: macrotask and microtask (Promises always use the microtask event queue). You can read more here:

https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

So the question is whether spawning Futures directly uses the JS microtask queue, or whether it uses a Rust dequeue.

Using the JS microtask queue is a lot simpler, but using a Rust dequeue is multiple orders of magnitude faster.

Here is a very old stdweb Executor which doesn't use a Rust dequeue, it spawns Futures directly using the JS Promise microtask queue.

It was written for Futures 0.1, it's quite old, probably buggy, and quite slow, but it is also simple and easy to understand, so hopefully it's educational.

[Pauan]

All of this event queue stuff is an implementation detail: the user just calls spawn_local and at some unknown point in the future the Future will run.

I say "unknown point", but it's usually very fast (a few milliseconds at most). The "unknown" part just means you can't rely upon it running at a deterministic point in time, since it's asynchronous.

[richard-uk1]

Thanks for the microtask reading - I feel like I understand all this stuff much better now!

[lcnr]

I am currently writing a small HttpRequest crate and ended up creating a wrapper struct with a custom Dropimplementation.

pub struct Request<T: Future + 'static = JsFuture>(Option<T>);   

/// snip ..

impl<T: Future + 'static> std::ops::Drop for Request<T> {
    fn drop(&mut self) {
        if let Some(future) = self.0.take() {
            future_to_promise(future.and_then(|_| {
                future::ok(JsValue::null())
            }).or_else(|_| {
                future::err(JsValue::null())
            }));
        }
    }
}

Now the browser is doing most of the work.

Usage:

  Request::new(Method::Get, "example.org/test")
        .header("Accept", "text/plain").send()
        .and_then(|resp_value: JsValue| {
            let resp: Response = resp_value.dyn_into().unwrap();
            resp.text()
        })
        .and_then(|text: Promise| {
            JsFuture::from(text)
        })
        .and_then(|body| {
            println!("Response: {}", body.as_string().unwrap());
            future::ok(())
        });

[Pauan]

@lcnr Running an asynchronous Future in the Drop impl seems pretty hacky to me.

If the goal is to cancel a fetch, you should use the standard AbortController, something like this:

pub struct Request<'a> {
    url: &'a str,
    init: RequestInit,
}

impl<'a> Request<'a> {
    pub fn new(url: &'a str) -> Self {
        Self {
            url,
            init: RequestInit::new(),
        }
    }

    pub fn send(mut self) -> RequestFuture {
        let controller = AbortController::new().unwrap();

        let init = self.init.signal(Some(&controller.signal()));

        let future = window().unwrap().fetch_with_str_and_init(self.url, &init).into();

        RequestFuture {
            controller,
            future,
        }
    }
}


pub struct RequestFuture {
    controller: AbortController,
    future: JsFuture,
}

impl Drop for RequestFuture {
    #[inline]
    fn drop(&mut self) {
        self.controller.abort();
    }
}

impl Future for RequestFuture {
    type Output = Result<JsValue, JsValue>;

    #[inline]
    fn poll(self: Pin<&mut Self>, waker: &LocalWaker) -> Poll<Self::Output> {
        self.future.poll_unpin(waker);
    }
}

Untested, but it should be close to correct.

[Pauan]

If your goal is instead to workaround the lack of spawn_local (or similar)... that's a very hacky solution.

Instead the correct solution is for us to add in spawn_local, which you would use in your main function.

[lcnr]

@Pauan I am not even sure what exactly I am doing. 😆 I want to make requests during which I return control of the main thread back to to browser/javascript and don't help to store the future anywhere. This means I am currently using a global state.

If your goal is instead to workaround the lack of spawn_local (or similar)... that's a very hacky solution.

jup

[Pauan]

I want to make requests during which I return control of the main thread back to to browser/javascript and don't help to store the future anywhere.

That happens naturally as part of the Promises/Futures system, you don't need to do anything special for that.

The best thing to do is to have Request::send return a Future (similar to what I showed in my previous post), and then you can use future_to_promise to spawn it in main:

#[wasm_bindgen(start)]
pub fn main() {
    future_to_promise(
         Request::new(Method::Get, "example.org/test")
            .header("Accept", "text/plain").send()
            .and_then(|resp_value: JsValue| {
                let resp: Response = resp_value.dyn_into().unwrap();
                resp.text()
            })
            .and_then(|text: Promise| {
                JsFuture::from(text)
            })
            .and_then(|body| {
                println!("Response: {}", body.as_string().unwrap());
                future::ok(JsValue::UNDEFINED)
            })
    );
}

No global state needed.

And then when spawn_local is supported you can just replace future_to_promise with spawn_local.

It's even nicer with async/await:

#[wasm_bindgen(start)]
pub fn main() {
    future_to_promise(async {
        let resp_value = await!(
            Request::new(Method::Get, "example.org/test")
                .header("Accept", "text/plain").send()
        )?;

        let resp: Response = resp_value.dyn_into().unwrap();
        let body = await!(JsFuture::from(resp.text()?))?;

        println!("Response: {}", body.as_string().unwrap());

        Ok(JsValue::UNDEFINED)
    });
}

Naturally you don't want to put everything into main, but that's not a problem: you can just split your program into multiple async functions:

async fn get_text(url: &str) -> Result<String, JsValue> {
    let resp_value = await!(
        Request::new(Method::Get, url).header("Accept", "text/plain").send()
    )?;

    let resp: Response = resp_value.dyn_into().unwrap();

    let body = await!(JsFuture::from(resp.text()?))?;

    Ok(body.as_string().unwrap())
}


async fn do_something() -> Result<(), JsValue> {
    let body = await!(get_text("example.org/test"))?;

    println!("Response: {}", body);

    Ok(())
}


#[wasm_bindgen(start)]
pub fn main() {
    future_to_promise(async {
        await!(do_something())?;
        Ok(JsValue::UNDEFINED)
    });
}

When you use await! on a Promise, it will yield control to the browser.

So in the above example, await!(Request::new(Method::Get, url).header("Accept", "text/plain").send()) and await!(JsFuture::from(resp.text()?)) will yield control.

await!(get_text("example.org/test")) and await!(do_something()) also yield control, since they call get_text (and get_text uses await! on Promises).

Using async/await in Rust is similar to async/await in JavaScript.

[Pauan]

P.S. async/await support will require #1105 to be fixed first (or I guess you can use the 0.1 to 0.3 Futures compatibility shim to make it work?).

Even without async/await, my point about using future_to_promise in main still stands.