-
Notifications
You must be signed in to change notification settings - Fork 285
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
feat(neon): Add tokio async runtime support #1055
Conversation
3da8a9e
to
3cfbd7a
Compare
c17a9ad
to
394b695
Compare
e1f61ca
to
1cc69a4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few small changes, but nothing major. TBH I'm a little worried my lack of expertise at tokio and async means my review might be a little superficial. But the API is so easy to understand and fits so nicely with the #[export]
macro syntax. This is a really exciting addition.
1cc69a4
to
1a4908b
Compare
ce2eed4
to
40e1e3d
Compare
40e1e3d
to
df091a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
This PR adds support for exporting
async fn
and future returnfn
in#[neon::export]
.It is intentionally very conservative in semver guarantees. It requires registering a global future executor. The executor must implement the private
Runtime
trait. Currently, only atokio
implementation is included. Additionally,Future
trait bounds are strict enough to allow for multi-threaded executors.As we see demand, we can add support for additional executors (e.g.,
async-std
) and possibly even single threaded executors (#[neon::export(?Sync)]
) or a built-inlibuv
driven executor. The eventual goal is to make theRuntime
trait public so that users can bring their own executor.Depends on improve(neon): Use autoref specialization for JSON wrapping return values in exported functions #1057(Merged)