Skip to content

Conversation

@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Jul 15, 2025

This is a follow-up to #11238 which adds &Accessor arguments to all functions for futures and streams. Like #11238 this is done to make future refactorings easier for the internal implementation but the internal implementations are not updated at this time. Many functions, for example, do not use the argument at all just yet. The purpose of this is to ensure host usage of these functions always provides a store context.

This change required large refactorings of the upcoming wasmtime-wasi-http implementation in the wasip3-prototyping repository. That's all been sorted out now though so the changes are being pulled back here into the Wasmtime repository as well.

This commit additionally changes the watch_* functions on the various stream/future types to take &mut self instead of self-by-value. This is mostly a stylistic change and is more API-driven than anything else. Functionally this behaves the same as before where, while watching, the stream/future cannot be read/written to otherwise.

cc #11224

This is a follow-up to bytecodealliance#11238 which adds `&Accessor` arguments to all
functions for futures and streams. Like bytecodealliance#11238 this is done to make
future refactorings easier for the internal implementation but the
internal implementations are not updated at this time. Many functions,
for example, do not use the argument at all just yet. The purpose of
this is to ensure host usage of these functions always provides a store
context.

This change required large refactorings of the upcoming
wasmtime-wasi-http implementation in the wasip3-prototyping repository.
That's all been sorted out now though so the changes are being pulled
back here into the Wasmtime repository as well.

This commit additionally changes the `watch_*` functions on the various
stream/future types to take `&mut self` instead of `self`-by-value. This is
mostly a stylistic change and is more API-driven than anything else.
Functionally this behaves the same as before where, while watching, the
stream/future cannot be read/written to otherwise.
@alexcrichton alexcrichton requested a review from a team as a code owner July 15, 2025 22:02
@alexcrichton alexcrichton requested review from dicej and fitzgen and removed request for a team and fitzgen July 15, 2025 22:02
@alexcrichton
Copy link
Member Author

Ah I also added a new AsAccessor helper trait here to assist with functions-taking-this-as-a-bound to make those a bit easier to write (in theory at least)

@github-actions github-actions bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Jul 15, 2025
@alexcrichton alexcrichton enabled auto-merge July 16, 2025 14:27
@alexcrichton alexcrichton added this pull request to the merge queue Jul 16, 2025
Merged via the queue into bytecodealliance:main with commit c34eb3f Jul 16, 2025
42 checks passed
@alexcrichton alexcrichton deleted the more-accessor-apis branch July 16, 2025 15:05
bongjunj pushed a commit to prosyslab/wasmtime that referenced this pull request Oct 20, 2025
…1250)

* Require `Accessor` on all future/stream functions

This is a follow-up to bytecodealliance#11238 which adds `&Accessor` arguments to all
functions for futures and streams. Like bytecodealliance#11238 this is done to make
future refactorings easier for the internal implementation but the
internal implementations are not updated at this time. Many functions,
for example, do not use the argument at all just yet. The purpose of
this is to ensure host usage of these functions always provides a store
context.

This change required large refactorings of the upcoming
wasmtime-wasi-http implementation in the wasip3-prototyping repository.
That's all been sorted out now though so the changes are being pulled
back here into the Wasmtime repository as well.

This commit additionally changes the `watch_*` functions on the various
stream/future types to take `&mut self` instead of `self`-by-value. This is
mostly a stylistic change and is more API-driven than anything else.
Functionally this behaves the same as before where, while watching, the
stream/future cannot be read/written to otherwise.

* Review comments
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.

3 participants