re-entrant/cooperative wasm?

[rrichardson]

Hello, apologies for asking this as an issue, but I'm not sure where else to ask questions of this nature.

Is it possible to deschedule and re-schedule running wasm tasks? I'd like to run dozens or hundreds of wasm programs in an app server of sorts, but running each in its own thread seems a tad excessive.

Is it possible to hand to running wasm code functions which are effectively async, and deschedule the wasm program while it is waiting on IO?

[pchickey]

These are very similar requirements to the ones we built Lucet for (https://github.com/bytecodealliance/lucet). We run WebAssembly code on a separate stack, and we have a yield API which is only accessible to host code called by WebAssembly code and returns back to the host stack, and a resume API to switch back to a suspended instance.

Our goal with Lucet is to merge it with Wasmtime by porting in all of the features that Wasmtime currently lacks, and this is one of the big ones.

We also want to transform the wasi-common (which lives in this repo) to take advantage of this, and perform all IO in an async rust function, for integration with tokio and friends. That work is still in its infancy, we're still working out other aspects of that story.

[Ekleog]

So I'm not totally sure what exactly is wanted from this issue, but I've just published the wasmtime-async crate that probably handles this problem -- though not yet handling wasi, due to limitations in the API, though hopefully these will be fixed soon-ish with #1600.

If so, I've opened #1672 for suggesting inclusion and/or referring to it from wasmtime's docs, to see what happens :)

[sunny-g]

@Ekleog url is missing the /crates path: wasmtime-async. Also, nicely done!

[rrichardson]

@Ekleog - This is fantastic!
I will get started with it today.

[alexcrichton]

I've opened bytecodealliance/rfcs#2 for what it might look like supporting this in wasmtime itself, curious to hear what others think!