bytecodealliance / bytecodealliance/wasmtime

async: Cancellation of a host async call does not have the opportunity to gracefully return a value

Open
#12,766 2 comments 0 reactions 0 assignees View on GitHub
wasm-proposal:component-model-async
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.