Fix/improve host subtask cancellation#12640
Fix/improve host subtask cancellation#12640alexcrichton merged 1 commit intobytecodealliance:mainfrom
Conversation
This commit refactors some of the internals of `subtask.cancel` with respect to host subtasks. Notably a few panics and semantic bugs are fixed here. The main bug was that host subtasks could be aborted but their completion might have still been queued up which would produce the result somewhere or assert that the task exists. Cancellation is changed to use `wait_for_event` to ensure that this completion is executed before `subtask.cancel` returns. This helps keep host subtasks looking more similar to guest subtasks in that respect. Closes bytecodealliance#12631 Closes bytecodealliance#12632 Co-authored-by: Jelle van den Hooff <[email protected]>
alexcrichton
force-pushed
the
fix-host-subtask-canel
branch
from
c514a7f to
ef2cb54
Compare
|
thanks for the fast fix! I couldn’t quite tell from reading the code if this will change the subtask.cancel behavior: will a cancel in progress now require the caller to wait before dropping? |
|
Spec-wise |
|
Great, thanks. I was so far relying on cancel and then an immediate drop working, so I’ll have to become spec compliant in my guest. That is of course what the code should have done in the first place… but it will require some thinking because cancel+drop was a nice instantaneous cleanup path. |
3 participants
This commit refactors some of the internals of
subtask.cancelwith respect to host subtasks. Notably a few panics and semantic bugs are fixed here. The main bug was that host subtasks could be aborted but their completion might have still been queued up which would produce the result somewhere or assert that the task exists. Cancellation is changed to usewait_for_eventto ensure that this completion is executed beforesubtask.cancelreturns. This helps keep host subtasks looking more similar to guest subtasks in that respect.Closes #12631
Closes #12632