Subtasks, wasi:cli/run, host invocations of functions, and relationships within

[alexcrichton]

Wasmtime's host API today is that when a function is invoked it returns both the function's return value and TaskExit. The TaskExit value has a single method, block, which is intended to transitively wait for all subtasks spawned by the original root task. This structure is used in a few situations:

• When running a CLI component the main thread blocks for this method
• When running an arbitrary function via --invoke the main thread waits on this before exiting
• When processing HTTP requests in wasmtime serve this is used as well

In discussions with @lukewagner and @dicej I've realized that Wasmtime's modeling of subtasks in this way is incorrect and needs to change. Effectively the TaskExit return value is going to need to be removed from Wasmtime because subtasks are tied to instances, not tasks themselves.

In doing this, however, it raises the question of what should be happening in all of these cases? For example at what point should wasi:cli/run "finish"? Is that the same answer as --invoke? Or is serve perhaps a bit different? I wanted to open this issue to write down some thoughts and have some possible discussion about this.

In the near-term what I plan to do is to add some sort of "wait for all tasks in this Store" method which will be used in all of these situations. That would mean, however, that a background task would keep the entire store alive and would keep Wasmtime from exiting. That's probably fine in the near-term but I don't think that this is a great long-term solution. I'm also not exactly sure what the solution might be and where it would lie, as the answer could be in WASI idioms or in the component model itself, unsure!

[lukewagner]

Thanks for filing, happy to discuss!

One idea that came up in #307 in the context of long-running/reused instances is that, just like there is currently a start function, there could also be a stop function. The stop function would be called by the host (or, in the future, by a parent component) to signal "I'd like to tear down your instance; please exit all running tasks so I can do it gracefully before a timeout". In the ideal case, all the component's background tasks would be notified that stop was called (e.g., maybe via guest wasi-libc atexit()) and then exit. But then after a host-determined timeout, the host would ungracefully zap the containing store (like it does now to kill iloops). So then, in the context of a host "wait for all tasks in this Store" method that you mentioned, the first thing this method could do is call the stop function for all component instances in the store, thereby telling all the background tasks to promptly exit to allow prompt graceful shutdown.

[badeend]

I think there's overlap with an issue I opened recently on the WASI repo: WebAssembly/WASI#858

That focuses only on the wasi:cli/run "foreground" task.
Yet, similar to this ticket, that WASI ticket has an (as of yet) unresolved question by Lann on how to properly propagate the shutdown request into the subtask/component tree.
Also it exhibits the same graceful shutdown UX, whether that's a simple timeout or waiting for a second Ctrl+C.

[lukewagner]

@badeend Interesting connection! Alex makes a good point on that issue regarding the trickiness of wiring up Ctrl+C to async cancellation in a wasi-libc / sigaction() context. But let's say that there is no WASI sigaction (or: it exists, but the component hasn't dynamically registered a SIGINT callback) and the CLI host receives a Ctrl+C. Instead of simply zapping the whole store or the whole process (which I expect is what would happen now?), maybe the runtime could call the stop functions on all the transitive component instances and then set a timeout to allow them to gracefully shut down before zapping them. And then perhaps wasi-libc could export a stop function (which, like start, we could allow multiple of, so that wasi-libc could do on its own without worrying about whatever else is linked into the component) and then wasi-libc could translate calls to stop into some appropriate { signal or atexit() or both or something else } call that background tasks could register for?

[alexcrichton]

One thing I'm now realizing is that my intention with this issue is different from WebAssembly/WASI#858, specifically where WebAssembly/WASI#858 is concerned with cancellation this issue is concerned about the meaning of the window of time between task-return and task-exit. This touches on WASI for sure, but as of now I'm not really sure what it means.

On one hand this is sort of "life after main returns" which I don't think has any real correspondence to meaning on native platforms (e.g. natively platforms all terminate the process when the main thread exits). Runtimes such as Java (or so I'm told by @dicej) will not exit the process on the main thread exiting but wait for all threads to exit as well. I don't know what to implement in Wasmtime.

In bytecodealliance/wasmtime#12185 Wasmtime's handling of CLI binaries was updated to avoid exiting the process until all subtasks spawned by the program exited. I'm second-guessing that now of I'm not sure whether we actually want that behavior at all. Even if there were a stop function or some way to signal cancellation, is this even the right point to do so? I can see stop/cancellation being quite relevant to wasi-http for example but for something like the CLI it seems less relevant as by returning from run I'd expect that's the conventional signal for "I'm done here goodbye".

Basically I want to clarify that even if there were a stop and even if there were a well-defined means of cancellation, I still don't know how to think about the window of time between return and exit. I don't know what WASI should specify runtimes should do when running run within this window of time -- for example I don't know if "block on everything in the store exiting" is correct nor if "cancel everything then block for a grace period then hard kill" is correct. To me the closest equivalent to a native platform is to hard kill everything after run returns with no chance for cleanup. If a guest language wants different behavior (e.g. Java) then it's up to the guest language to avoid returning.

For wasmtime serve what I'd expect is that the store is "strong referenced" while any streams are in active use (e.g. incoming or outgoing or such). Once all that goes away the store is eligible to get zapped at any time, where in the future we'd use stop and/or cancellation to more gracefully allow that. In this case though I also don't see a purpose for blocking on all spawned subtasks within the store, however.

[alexcrichton]

Some more history on the Wasmtime side of things:

• Expose when component model async tasks finish, not just return bytecodealliance/wasmtime#11600 - original issue about surfacing this abstraction (time between return/exit) in Wasmtime
• return TaskExit future from [Typed]Func::call_concurrent bytecodealliance/wasmtime#11662 - original implementation
• add task_exit option to wasmtime-wit-bindgen bytecodealliance/wasmtime#11665 - more bindgen options