JavaScript Promise & Rust Future Interoperability

[redfire75369]

JavaScript Promise & Rust Future Interoperability

[Redfire75369]

This has now been completed with f4e4483.

The API is as follows:

let future = async {
    return Ok(4);
};

let promise = IonPromise::from_future(rt.cx(), future);
unsafe { global.set_as(rt.cx(), "promiser".into(), IonObject::from(promise.raw())); }
assert!(IonScript::compile_and_evaluate(rt.cx(), "inline.js", "promiser.then(v => console.log(v))").is_ok());

As of 7a2faf5, #[js_fn] macros can also be used to create functions that return promises.

async fn async_increment(int: u64) -> u64 { int + 1 }

#[js_fn]
async unsafe fn async_fn(int: u64) -> Result<u64, ()>{
    Ok(async_increment(int).await)
}

This issue will be kept open for a week for any bugs in the API or possible improvements to the API.

[sagudev]

Why function unsafe?

[Redfire75369]

In #[js_fn]? It's the same for synchronous functions too. It's across FFI, so I think it's fair.

[sagudev]

Yes but this function is called from other unsafe function that does the args conversion, which means that this function (async_increment) is safe, but it's callee is unsafe. So I would make unsafe fn on js_fn optional.

[Redfire75369]

After having talks with some people on the safety/unsafety of this function, it seems that it is still unsafe as long as panics have undefined behaviour. The solution to that seems to be catch_unwind.

I suppose that it could just return an Err() if a panic occurs. This means it would return false from the native function, showing that there was an internal "exception".

[Redfire75369]

As of e333e88, panicking within native functions is no longer undefined behaviour. The output is still a bit weird, but can be improved later.

As there are no further comments on the API for asynchronous functions, this issue will be closed.