-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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(wasmtime-cli): restore support for wasi http module #6878
feat(wasmtime-cli): restore support for wasi http module #6878
Conversation
fd6cecb
to
9148521
Compare
9148521
to
b743ff2
Compare
Thanks! Could you expand a bit more on the rationale for this? Why would users of the CLI want to control async-vs-not? Or is this instead intended for testing the async implementations on the CLI? |
Just added more details to the PR body itself. |
This isn't the correct approach - instead, futures::executor isnt the right executor to use with wasmtime-wasi, it will fall over if not used with tokio. |
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasi", "wasmtime:api", "wasmtime:c-api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
Within the wasmtime CLI, the current default behavior is to only inject the synchronous functions to linkers. This will add a flag called `--async` that will inject the asynchronous one instead.
This reverts commit b743ff2.
08c09dc
to
9401c72
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.
With a few changes we can accept this PR, thanks!
Just as a heads up, I know you put a lot of labor into keeping the core-wasm wasmtime::Linker
version of this code working, including the sync side of the bindings. We'll keep those working for the wasmtime 13 release, but after that we are going to swap the implementation over to use wasmtime-wasi::preview2 streams and pollables, as well as component resource types. When we make that switch, we will deprecate the core-wasm interfaces, since we don't want to maintain both.
i32.const 0 ;; base pointer | ||
i32.const 0 ;; length | ||
)) | ||
(local.set $request_id (call $__wasi_http_types_new_outgoing_request |
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 is impressive! nice job
} | ||
#[cfg(feature = "component-model")] | ||
CliLinker::Component(linker) => { | ||
wasmtime_wasi_http::proxy::sync::add_to_linker(linker)?; |
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.
Using wasi-http with the component::Linker will fail because it conflicts with the stream methods in the wasmtime-wasi::preview2 implementation. So, we should instead bail
in this case.
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.
that is actually not case because we are taking the implementation from the wasmtime-wasi
crate when building the bindings:
wasmtime/crates/wasi-http/src/proxy.rs
Lines 53 to 54 in 75f3da7
"wasi:io/streams": preview2::bindings::sync_io::io::streams, | |
"wasi:poll/poll": preview2::bindings::sync_io::poll::poll, |
we should be able to migrate the cli test to a component when the module code is deprecated.
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.
right, but without actually using HostInputStream and HostOutputStream, it will still crash at runtime.
Looks like there is some sort of cargo issue that happens when building the cli, which doesnt happen in the usual set of tests that runs before the merge queue runs the full set. Put the string |
9c3d9af
to
968da10
Compare
968da10
to
e56a4dd
Compare
@alexcrichton and @pchickey, could wasi-http be enabled back in the wasmtime v13 release branch, please? Otherwise, there will be no release with module support for this. |
AFAIK that was the plan yeah, so seems reasonable to me. The process for doing so would require a PR to the |
…iance#6878) * feat(wasmtime-cli): add async support flag Within the wasmtime CLI, the current default behavior is to only inject the synchronous functions to linkers. This will add a flag called `--async` that will inject the asynchronous one instead. * chore: refactor wasi http crate * feat(wasmtime-wasi): make in_tokio function public * feat(wasi-http): define default feature called sync * Revert "feat(wasmtime-cli): add async support flag" This reverts commit b743ff2. * chore: improve flaky tests for wasi http * feat(wasi-http): expose sync api for components * chore: add tests for sync api of wasi http components * feat(wasmtime-cli): restore support for wasi http module * chore: revert change to outbound http request invalid test * chore: have extra tracing to help debugging * feat(wasi-http): allow modules with sync functions in linker * fix(wasi-http): missing response body in sync api * feat: include blocking for io streams * chore: add tests for wasi http module in cli * chore: disable preview2 flag in wasi http test * chore: use preview2 flag in wasi http test * fix(wasi-http): missing stream output in sync api * chore: fix tests for wasi http * chore: add tracing for poll oneoff call * chore: send exit signal on wasi http test * chore: swap println to tracing debug * chore: set http server timeout to 50 secs by default * chore: add test posting large file * chore: revert formatting in cargo toml * chore: fix wasi-http feature and skip failing tests prtest:full --------- Co-authored-by: Eduardo Rodrigues <[email protected]>
…iance#6878) * feat(wasmtime-cli): add async support flag Within the wasmtime CLI, the current default behavior is to only inject the synchronous functions to linkers. This will add a flag called `--async` that will inject the asynchronous one instead. * chore: refactor wasi http crate * feat(wasmtime-wasi): make in_tokio function public * feat(wasi-http): define default feature called sync * Revert "feat(wasmtime-cli): add async support flag" This reverts commit b743ff2. * chore: improve flaky tests for wasi http * feat(wasi-http): expose sync api for components * chore: add tests for sync api of wasi http components * feat(wasmtime-cli): restore support for wasi http module * chore: revert change to outbound http request invalid test * chore: have extra tracing to help debugging * feat(wasi-http): allow modules with sync functions in linker * fix(wasi-http): missing response body in sync api * feat: include blocking for io streams * chore: add tests for wasi http module in cli * chore: disable preview2 flag in wasi http test * chore: use preview2 flag in wasi http test * fix(wasi-http): missing stream output in sync api * chore: fix tests for wasi http * chore: add tracing for poll oneoff call * chore: send exit signal on wasi http test * chore: swap println to tracing debug * chore: set http server timeout to 50 secs by default * chore: add test posting large file * chore: revert formatting in cargo toml * chore: fix wasi-http feature and skip failing tests prtest:full --------- Co-authored-by: Eduardo Rodrigues <[email protected]>
* feat(wasmtime-cli): add async support flag Within the wasmtime CLI, the current default behavior is to only inject the synchronous functions to linkers. This will add a flag called `--async` that will inject the asynchronous one instead. * chore: refactor wasi http crate * feat(wasmtime-wasi): make in_tokio function public * feat(wasi-http): define default feature called sync * Revert "feat(wasmtime-cli): add async support flag" This reverts commit b743ff2. * chore: improve flaky tests for wasi http * feat(wasi-http): expose sync api for components * chore: add tests for sync api of wasi http components * feat(wasmtime-cli): restore support for wasi http module * chore: revert change to outbound http request invalid test * chore: have extra tracing to help debugging * feat(wasi-http): allow modules with sync functions in linker * fix(wasi-http): missing response body in sync api * feat: include blocking for io streams * chore: add tests for wasi http module in cli * chore: disable preview2 flag in wasi http test * chore: use preview2 flag in wasi http test * fix(wasi-http): missing stream output in sync api * chore: fix tests for wasi http * chore: add tracing for poll oneoff call * chore: send exit signal on wasi http test * chore: swap println to tracing debug * chore: set http server timeout to 50 secs by default * chore: add test posting large file * chore: revert formatting in cargo toml * chore: fix wasi-http feature and skip failing tests prtest:full --------- Co-authored-by: Eduardo Rodrigues <[email protected]>
Within the wasmtime CLI, the current default behavior is to only inject the synchronous functions to linkers. This will add a flag called--async
that will inject the asynchronous one instead.This is required in order to enable back thewasi-http
module because it has been implemented only with async functions. Additionally, it will help the async support code path to be tested as async should be enabled by default in the future.This will enable back the
wasi-http
module within the wasmtime CLI. We will make the bindgen synchronous through the tokio executor available in wasmtime.