bytecodealliance / bytecodealliance/wasmtime
async: Cancellation of a host async call does not have the opportunity to gracefully return a value
- Dominant language
- Rust
- Stars
- 18.6k
- Forks
- 1.8k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 121
Description
Currently in Wasmtime with component-model-async when a host function is cancelled the future representing that host function is simply dropped. I believe that the future gets a single final `poll` to produce a result before being dropped, but fundamentally Wasmtime doesn't provide embedders a means by which to gracefully handle the cancellation signal. This means that it's not easy or possible to impelement a sort of "atomic cancellation" in Wasmtime today where upon receiving cancellation some operation may already be complete but it is unable to communicate that. This is inspired by discussion [here](https://github.com/WebAssembly/WASI/issues/897#issuecomment-4007885904) w.r.t cancelling UDP `send` operations.
Some possible shapes of a solution here are:
* Instead of returning a return value, hosts could be provided an object through which the return value is transmitted. This models `task.return` more closely and bindings generation could paper over the differences here. This would enable hosts to at least provide a return value in a `Drop` implementation.
* Hosts could be provided a sort of `CancellationToken` which has helper methods/etc to test/await it. Wasmtime would then not actually drop the future at all, but it would instead set the `CancellationToken` and continue polling as usual. It'd be up to embedders to drop futures, for example.
Contributor guide
Assessment
This issue has not been assessed yet.