-
Notifications
You must be signed in to change notification settings - Fork 312
flesh out async support in wit-dylib
#2367
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
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This does two things: First, it adds a low-level API to `wit-dylib-ffi` for async imports and exports as an alternative to the high-level API based on `wit-bindgen`'s `rt` library and enabled with the `async` feature. Thus enabling the `async` feature now really just means "use the high-level API", while disabling it means "use the low-level API". The low-level API can make more sense for e.g. Python, where the coroutine model is different enough from Rust's that it's easier to map it directly to the component model ABI rather than try to plumb it through Rust's async APIs. Second, it populates the `wit_future` and `wit_stream` types with all the relevant intrinsics, ABI size/align metadata, and generated payload lift and lower functions. I've tested this all end-to-end with `componentize-py`, but could use some guidance on how to add tests here as well. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
03c8650 to
416c5da
Compare
alexcrichton
approved these changes
Nov 5, 2025
Member
alexcrichton
left a comment
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.
Thanks! Mind adding some simple tests here too?
2edb104 to
cf74db9
Compare
- `async-runtime`: integrates with `std::future` by way of `wit_bindgen::rt` - `async-raw`: minimal layer over raw bindings; does not use `std::future` or `wit_bindgen` Note that these are mutually exclusive; enabling both will result in a compiler error. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
cf74db9 to
f40aa78
Compare
...and add a comment explaining why it's still needed in `lower_payload`. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
28a7c25 to
155bd0e
Compare
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
155bd0e to
dbc176e
Compare
Collaborator
Author
|
The CI failures are due to issues fixed in bytecodealliance/wasmtime#11981. The tests pass when using Wasmtime |
73646a4 to
dbc176e
Compare
mxgordon
pushed a commit
to YellowPapayas/wasm-tools
that referenced
this pull request
Nov 11, 2025
* flesh out async support in `wit-dylib` This does two things: First, it adds a low-level API to `wit-dylib-ffi` for async imports and exports as an alternative to the high-level API based on `wit-bindgen`'s `rt` library and enabled with the `async` feature. Thus enabling the `async` feature now really just means "use the high-level API", while disabling it means "use the low-level API". The low-level API can make more sense for e.g. Python, where the coroutine model is different enough from Rust's that it's easier to map it directly to the component model ABI rather than try to plumb it through Rust's async APIs. Second, it populates the `wit_future` and `wit_stream` types with all the relevant intrinsics, ABI size/align metadata, and generated payload lift and lower functions. I've tested this all end-to-end with `componentize-py`, but could use some guidance on how to add tests here as well. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * split `wit-dylib` `async` feature into `-raw` and `-runtime` variations - `async-runtime`: integrates with `std::future` by way of `wit_bindgen::rt` - `async-raw`: minimal layer over raw bindings; does not use `std::future` or `wit_bindgen` Note that these are mutually exclusive; enabling both will result in a compiler error. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * remove unnecesary stack frame from `lift_payload` ...and add a comment explaining why it's still needed in `lower_payload`. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * add stream and future tests Signed-off-by: Joel Dice <joel.dice@fermyon.com> * Install dev tag of wasmtime --------- Signed-off-by: Joel Dice <joel.dice@fermyon.com> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
mxgordon
added a commit
to YellowPapayas/wasm-tools
that referenced
this pull request
Nov 11, 2025
This reverts commit 3b22384.
mxgordon
added a commit
to YellowPapayas/wasm-tools
that referenced
this pull request
Nov 11, 2025
This reverts commit 3b22384.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This does two things:
First, it adds a low-level API to
wit-dylib-ffifor async imports and exports as an alternative to the high-level API based onwit-bindgen'srtlibrary and enabled with theasyncfeature. Thus enabling theasyncfeature now really just means "use the high-level API", while disabling it means "use the low-level API". The low-level API can make more sense for e.g. Python, where the coroutine model is different enough from Rust's that it's easier to map it directly to the component model ABI rather than try to plumb it through Rust's async APIs.Second, it populates the
wit_futureandwit_streamtypes with all the relevant intrinsics, ABI size/align metadata, and generated payload lift and lower functions.I've tested this all end-to-end with
componentize-py, but could use some guidance on how to add tests here as well.