Skip to content

add Func::ready_to_call and use it in wasmtime_wasi_http::handler#13683

Open
dicej wants to merge 2 commits into
bytecodealliance:mainfrom
dicej:func-ready-to-call
Open

add Func::ready_to_call and use it in wasmtime_wasi_http::handler#13683
dicej wants to merge 2 commits into
bytecodealliance:mainfrom
dicej:func-ready-to-call

Conversation

@dicej

@dicej dicej commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

This allows the caller to wait for the underlying component instance to be ready to call, i.e. for any outstanding sync calls to finish and for backpressure to be disabled, if applicable.

This is particularly useful in wasmtime_wasi_http::handler where we need to decide whether a given worker is available to handle additional requests. Previously, that decision did not take backpressure into account, meaning the worker would continue to accept requests even when the guest had enabled backpressure. However, a worker whose guest has enabled backpressure should not accept new requests; instead, it should mark itself unavailable and allow another worker to accept them.

This allows the caller to wait for the underlying component instance to be ready
to call, i.e. for any outstanding sync calls to finish and for backpressure to
be disabled, if applicable.

This is particularly useful in `wasmtime_wasi_http::handler` where we need to
decide whether a given worker is available to handle additional requests.
Previously, that decision did not take backpressure into account, meaning the
worker would continue to accept requests even when the guest had enabled
backpressure.  However, a worker whose guest has enabled backpressure should
_not_ accept new requests; instead, it should mark itself unavailable and allow
another worker to accept them.
@dicej dicej requested a review from alexcrichton June 17, 2026 23:21
@dicej

dicej commented Jun 17, 2026

Copy link
Copy Markdown
Contributor Author

I'm planning to add a test for this tomorrow; leaving as a draft until then.

@github-actions github-actions Bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Jun 18, 2026
@dicej dicej marked this pull request as ready for review June 18, 2026 19:24
@dicej dicej requested review from a team as code owners June 18, 2026 19:24
Comment on lines +5724 to +5728
pub(crate) struct ReadyToCall<'a, T: 'static, D: HasData + ?Sized> {
accessor: &'a Accessor<T, D>,
func: Func,
waker_key: Option<Resource<Waker>>,
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this perhaps be modeled as a poll_* function instead of an async function to avoid the need to have a list of wakers to wake up? Similar to Accesor::poll_no_interesting_tasks which makes the API contract clear. I think one-warker-per instance is all we need for wasi:http, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasmtime:api Related to the API of the `wasmtime` crate itself

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants