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?
There was a problem hiding this comment.
Oh right, good points! this is why I added the poll method originally on Accessor since it was more clear that there's just one of those and that's where the ownership lies. Would that work for wasmtime-wasi-http as well? Or does this need to genuinely register multiple wakers for an instance?
There was a problem hiding this comment.
The thing about Accessor is you only ever get a shared reference to it, so there's still no clear ownership involved. Also, an Accessor can cover any number of RuntimeInstances, each of which may become ready to call independently of each other.
I suppose you could have an Accessor::poll_ready_to_call which only fires when all RuntimeInstances owned by that store are ready to call, but that seems too coarse-grained to me. Consider the case of composition when a subcomponent instance has backpressure enabled but the top-level instance does not; we shouldn't insist that the whole composition is not ready to call just because one part of it isn't. Similarly, if the store has multiple top-level instances and only one of them has backpressure enabled, that shouldn't block calling into other instances.
Overall, I think the most useful and least surprising approach is to support multiple wakers. I realize that has implementation complexity and efficiency costs, but I think they're worth the benefits in this case.
There was a problem hiding this comment.
I agree about the downsides of an Accessor::poll_* method, yeah, but to me the benefit is that this relatively niche use case is carrying a quite large, heavyweight, and inefficient data structure, ResourceTable, on all instances now. I'd prefer to avoid that if possible, and for the use case at-hand I believe at most one-per-instance is all that's required. With an explicit poll_* method we've got the ability to clearly document how many wakers are supported and so I'm not too too worried about it being a problem for accidental mis-use. We also always have the ability to extend this in the future if necessary, too
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.