Alex Crichton (Sep 02 2025 at 18:00): Alex Crichton (Sep 02 2025 at 18:00):@Joel Dice let's say I invoke an async guest function from the host. The guest calls task.return and then sleeps for 10s. Does the host-side future resolve immediately on task.return or does it wait for the task to exit?
Lann Martin (Sep 02 2025 at 18:14):It should be immediate, right?
Alex Crichton (Sep 02 2025 at 18:15):I suppose this is was a leading question, but I'm under the impression it's not immediate currently. I was about to open an issue for making it immediate but wanted to confirm first.
If it is immediate, however, then we also need more API bindings since right now the host otherwise has no way of knowing when the task has exited after returning
Alex Crichton (Sep 02 2025 at 18:16):so, yes, I agree it should probably be immediate, but in doing so we need to expose the "task exited" event too
Lann Martin (Sep 02 2025 at 18:17):Is the task that returned special from the caller's perspective compared to any other task that might have been created?
Alex Crichton (Sep 02 2025 at 18:18):To me it is insofar as it represents the guests request to keep running after returning, so if the host wants to respect that it needs to know when the guest is done
Lann Martin (Sep 02 2025 at 18:20):Oh right this is meaningful because of the pseudo-structured-concurrency thing
Alex Crichton (Sep 02 2025 at 18:21):well the host wouldn't have a guarantee that when the guest task exits that there's no transitive tasks, so it's not structured in that sense
Alex Crichton (Sep 02 2025 at 18:21):but basically if everyone wants to participate in the structured concurrency paradigm it should be possible IMO
Lann Martin (Sep 02 2025 at 18:23):Do borrows have to be dropped before task.return or before task exit?
Lann Martin (Sep 02 2025 at 18:27):before task.return, I see
Lann Martin (Sep 02 2025 at 18:29):Alex Crichton said:
well the host wouldn't have a guarantee that when the guest task exits that there's no transitive tasks, so it's not structured in that sense
I think it should, if this is implemented (and applies to the host)
Alex Crichton (Sep 02 2025 at 18:32):aha good point, and now I also don't know whether that's implemented
Joel Dice (Sep 02 2025 at 19:19):Currently, there's no convenient way to wait for a task to exit in the Wasmtime API. I was thinking we could make call_concurrent return a tuple of the result and a future that resolves when the task exits; that should be easy enough to do, but isn't implemented yet.
Technically, you can also pass a forever-pending future to Instance::run_concurrent and wait for it to return a "deadlock" trap, which means "the runtime has nothing left to do". We use that hack in a few tests to wait for all outstanding tasks to exit, but it's obviously not a great long-term solution, plus it won't help if you only care about a specific task exiting.
Alex Crichton (Sep 02 2025 at 19:19):Ah ok, so task.return is indeed immediate today?
Joel Dice (Sep 02 2025 at 19:33):Yes.
Last updated: Dec 06 2025 at 06:05 UTC