add Func::ready_to_call and use it in wasmtime_wasi_http::handler#13683
add Func::ready_to_call and use it in wasmtime_wasi_http::handler#13683dicej wants to merge 2 commits into
Func::ready_to_call and use it in wasmtime_wasi_http::handler#13683Conversation
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.
|
I'm planning to add a test for this tomorrow; leaving as a draft until then. |
github-actions
Bot
added
the
wasmtime:api
| pub(crate) struct ReadyToCall<'a, T: 'static, D: HasData + ?Sized> { | ||
| accessor: &'a Accessor<T, D>, | ||
| func: Func, | ||
| waker_key: Option<Resource<Waker>>, | ||
| } |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Good call. I'll do that on Monday.
There was a problem hiding this comment.
Okay, I just sat down to do this, but realized that Func::ready_to_call is a lot more specific than Accessor::poll_no_interesting_tasks. The former concerns a specific RuntimeInstance of a specific Store, whereas the latter concerns only a specific Store. Also, if we turned it into Func::poll_ready_to_call it wouldn't be as clear to the caller that calling that function could overwrite the Waker set by an earlier call to poll_ready_to_call on a different Func that happened to belong to the same RuntimeInstance. And the fact that Func, RuntimeInstance, etc. are Copy makes ownership ambiguous, which could lead to further confusion about which poll_ready_to_call invocation will update which Waker.
Thoughts?
2 participants
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::handlerwhere 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.