Subtask cancellation

[alexcrichton]

I've talked about this with @lukewagner @dicej and others but I realized we don't have an issue on this, so I wanted to open one. Namely the current thinking is that while the explainer as-is has no recourse for subtask cancellation and we thought we might be able to defer this to post 0.3.0 we now agree that this needs to be implemented pre-0.3.0. This issue is intended to track this.

From a spec perspective we need to write down the various interactions and such with respect to cancellation of subtasks. I've sketched out some ideas in bytecodealliance/wit-bindgen#1264 to get a feel for what this might look like in the guest bindings. My current thinking is along the lines of:

• A new subtask.cancel canon builtin with signature [i32] -> [i32]
  • Takes a subtask id as an argument
  • Returns a task status code as a result
• Two new states for a subtask to be in: STATUS_{STARTED,RETURNED}_CANCELLED
  • Indicates a subtask has been succesfully cancelled
  • STATUS_STARTED_CANCELLED means that cancellation happened before the parameters were received, e.g. the STARTED state was never reached.
  • STATUS_RETURNED_CANCELLED means that cancellation happened after the parameters were received, e.g. the RETURNED state was never reached.
• A new EventCode.CANCELLED is added
  • Unsure if a new callback return code is needed?

I suspect I'm missing a lot of details here still as well.

[alexcrichton]

One thing I learned while working on the Rust guest: there's no easy way to actually recover the parameters in the event of cancellation. For example STATUS_STARTED_CANCELLED means that the parameters, in theory, could be returned back to the caller. The Rust generator, however, has no means of lifting a borrow<T> in this context right now since it's assumed that lifting a borrow<T> only happens at the "root export" level where there's some special handling to stack-root things, but that's not possible in this context. Not a major issue since we weren't planning on exposing this in Rust anyway, but a possible roadblock for the future.

[dicej]

FWIW, I'm about to start implementing the host side of this in wasip3-prototyping

Unsure if a new callback return code is needed?

Based on our earlier conversation, no such code is needed. The callback should call either task.cancel or task.return upon receiving EventCode.CANCELLED and then return CallbackCode.EXIT.

[lukewagner]

That all sounds good to me! I'll start writing this up.