Stream: git-wasmtime

Topic: wasmtime / PR #13683 add `Func::ready_to_call` and use it...

Wasmtime GitHub notifications bot (Jun 17 2026 at 23:21):

dicej opened PR #13683 from dicej:func-ready-to-call to bytecodealliance:main:

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.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Jun 17 2026 at 23:21):

dicej requested alexcrichton for a review on PR #13683.

Wasmtime GitHub notifications bot (Jun 17 2026 at 23:21):

dicej commented on PR #13683:

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

Wasmtime GitHub notifications bot (Jun 18 2026 at 01:34):

github-actions[bot] added the label wasmtime:api on PR #13683.

Wasmtime GitHub notifications bot (Jun 18 2026 at 18:57):

dicej updated PR #13683.

Wasmtime GitHub notifications bot (Jun 18 2026 at 19:24):

dicej has marked PR #13683 as ready for review.

Wasmtime GitHub notifications bot (Jun 18 2026 at 19:24):

dicej requested wasmtime-wasi-reviewers for a review on PR #13683.

Wasmtime GitHub notifications bot (Jun 18 2026 at 19:24):

dicej requested wasmtime-core-reviewers for a review on PR #13683.

Wasmtime GitHub notifications bot (Jun 19 2026 at 00:57):

:memo: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jun 19 2026 at 00:57):

:speech_balloon: alexcrichton created PR review 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?

Wasmtime GitHub notifications bot (Jun 20 2026 at 01:10):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (Jun 20 2026 at 01:10):

:speech_balloon: dicej created PR review comment:

Good call. I'll do that on Monday.

Wasmtime GitHub notifications bot (Jun 20 2026 at 22:55):

:thumbs_up: alexcrichton submitted PR review:

er, meant to do this

Wasmtime GitHub notifications bot (Jun 22 2026 at 14:14):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (Jun 22 2026 at 14:14):

:speech_balloon: dicej created PR review 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?

Wasmtime GitHub notifications bot (Jun 29 2026 at 14:00):

:memo: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jun 29 2026 at 14:00):

:speech_balloon: alexcrichton created PR review 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?

Wasmtime GitHub notifications bot (Jul 01 2026 at 14:29):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 01 2026 at 14:29):

:speech_balloon: dicej created PR review 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.

Wasmtime GitHub notifications bot (Jul 01 2026 at 18:31):

:memo: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 01 2026 at 18:31):

:speech_balloon: alexcrichton created PR review 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

Wasmtime GitHub notifications bot (Jul 01 2026 at 21:09):

dicej updated PR #13683.

Wasmtime GitHub notifications bot (Jul 01 2026 at 21:10):

dicej commented on PR #13683:

@alexcrichton I just pushed an update. Please let me know what you think.

Wasmtime GitHub notifications bot (Jul 01 2026 at 21:11):

dicej updated PR #13683.

Wasmtime GitHub notifications bot (Jul 01 2026 at 23:07):

:thumbs_up: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 01 2026 at 23:07):

alexcrichton added PR #13683 add Func::ready_to_call and use it in wasmtime_wasi_http::handler to the merge queue

Wasmtime GitHub notifications bot (Jul 01 2026 at 23:31):

:check: alexcrichton merged PR #13683.

Wasmtime GitHub notifications bot (Jul 01 2026 at 23:31):

alexcrichton removed PR #13683 add Func::ready_to_call and use it in wasmtime_wasi_http::handler from the merge queue

Last updated: Jul 29 2026 at 05:03 UTC