Wasmtime GitHub notifications bot (Sep 05 2025 at 17:45): Wasmtime GitHub notifications bot (Sep 05 2025 at 17:45):dicej opened PR #11625 from dicej:sync-stream-future-cancel to bytecodealliance:main:
This is a WIP and not yet tested.
<!--
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.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Sep 08 2025 at 17:48):dicej updated PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:00):dicej updated PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:05):dicej updated PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:07):dicej updated PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:16):dicej updated PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:17):dicej edited PR #11625:
During my earlier stream API refactoring, I had forgotten to support or test synchronous cancellation; this commit does both. In the process, I realized the future API ought to be updated to support blocking cancellation just like the stream API, so I made that change as well.
This also adds
{Source,Destination}::reborrowfunctions, allowing instances of those types to be reborrowed, such that they may be passed as parameters but also used again.Note that I had to move some functions from
impl ConcurrentStatetoimpl Instancein order to access the store and suspend the current fiber when synchronously cancelling.<!--
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.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:19):dicej has marked PR #11625 as ready for review.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:19):dicej requested wasmtime-wasi-reviewers for a review on PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:19):dicej requested fitzgen for a review on PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:19):dicej requested wasmtime-core-reviewers for a review on PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:20):dicej requested rvolosatovs for a review on PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:20):dicej requested alexcrichton for a review on PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:34):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:34):alexcrichton created PR review comment:
This looks like it's mostly a copy/paste of the above, and my suspicion is that it's likely pretty close to what's elsewhere too. Would it be possible to refactor this all to a common "block waiting for a result" function?
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:34):alexcrichton created PR review comment:
This reminds me of something we may wish to talk more about later, but I keep being endlessly confused about the
finish: boolparameter here. I feel like the way this is handled practically everywhere is to do exactly what this is doing which is to just pretend it's done whenfinishis flagged.Initially reading this I thought "wait shouldn't this close the oneshot and then look at the result?" but that's not correct because the host could re-initiate a read later on. I don't know of a great answer to this, nor is this PR the place to necessarily work this all out, but I feel like we need to change something about this either API-wise or such.
Wasmtime GitHub notifications bot (Sep 08 2025 at 18:53):dicej updated PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 19:40):dicej updated PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 19:40):dicej has enabled auto merge for PR #11625.
Wasmtime GitHub notifications bot (Sep 08 2025 at 20:16):dicej merged PR #11625.
Last updated: Dec 06 2025 at 06:05 UTC