-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redesigned support for futures. #156
Conversation
I have encountered some problems when trying to use closures which return futures. let closure = |ctx: Ctx| async move {
// Use ctx
std::mem::drop(ctx);
}; While the following equivalent functions works fine. async fn f|ctx: Ctx|{
// Use ctx
std::mem::drop(ctx);
}; Playground link |
Motivation
Rquickjs support mapping Javascript promises to futures and vice versa via the
Promise
andPromised
types.This allows the rquickjs library to interface with async rust.
However the current implementation has a few problems:
First, any access to the Javascript runtime in rquickjs has to go through a lock.
When the
parallel
feature is enabled this lock is done with a mutex.Blocking locks are a big no-no in async rust, instead we should use a async-aware mutex.
Second, futures in rquickjs currently require that the future is valid for
'static
.This leads to a bit of a problem when trying to use rquickjs functions as basically all functionality has the
'js
lifetime attached to it.This prevents functions like the one below from being implemented as
Function
is not valid for'static
as it has the'js
lifetime.This severely limits the actual usefulness of the using futures with rquickjs.
Futures spawned inside the runtime should probably only require a lifetime of
'js
.Implementation
This PR is an attempt to address these problems.
First it introduces
AsyncRuntime
andAsyncContext
, variants of runtime and context which use a async-aware mutex.As a result almost all methods of these types are asynchronous.
This version of context is used together with the
async_with
macro, which allows the with closure to return a future:Second it lifts the
'static
requirement for futures used inPromise
andPromised
.This allows futures to keep Javascript objects, as in the above example, allowing one to implement for example the
delay
function much easier than is currently possible (see #128).Finally it makes the library completely async runtime agnostic, all features are just implemented on top of the standard library future types and thus the library no longer needs to depend on tokio, async-std or smol and the rquickjs crate features implementing functionality for those runtimes have been removed.