guest-rust: Implement a Task handle for spawned futures - #1710
Conversation
The `Task` can be awaited to get the returned value of the future, or it can be dropped or explicitly canceled to cancel the future. It can also be detached to allow running in the background and match the previous behavior of `spawn_local`. It's possible that the component-model task into which the future was spawned could be canceled while the `Task` referencing it is still alive. In that case, awaiting or canceling the task will return `None`.
alexcrichton
left a comment
alexcrichton
left a comment
There was a problem hiding this comment.
Looks good to me! One final minor comment, and I think tests are timing out and/or infinite looping in CI
| if let Poll::Ready(()) = sender.poll_canceled(cx) { | ||
| return Poll::Ready(()); | ||
| } | ||
| // SAFETY: `fut` has not been moved. | ||
| let fut = unsafe { Pin::new_unchecked(&mut inner.fut) }; | ||
| match fut.poll(cx) { | ||
| Poll::Ready(t) => { | ||
| let _ = sender.send(t); | ||
| Poll::Ready(()) | ||
| } | ||
| Poll::Pending => { | ||
| inner.sender = Some(sender); | ||
| Poll::Pending | ||
| } | ||
| } |
There was a problem hiding this comment.
Could the order of these be swapped to check-the-future then check-the-cancel? That way a race of the two has the value production always win (sort of a last-attempt)
|
Actually using |
|
Oh, right, of course! In that case |
2 participants
The
Taskcan be awaited to get the returned value of the future, or it can be dropped or explicitly canceled to cancel the future. It can also be detached to allow running in the background and match the previous behavior ofspawn_local.It's possible that the component-model task into which the future was spawned could be canceled while the
Taskreferencing it is still alive. In that case, awaiting or canceling the task will returnNone.Note: The naming and cancellation behavior here matches
async_task::Taskbecause that's what we were already using inwstdand it would allow switching towit_bindgen::Taskwithout requiring a wrapper. But I could also see an argument for going with the naming and behavior oftokio, so happy to switch to that if other people think it's better.