Wasmtime: Tracking issue for guest stack switching in Wasmtime

[kubkon]

I thought it might be useful to have some sort of a tracker for stack suspending/switching functionality in Wasmtime which is required if we want to have async WASI on top of tokio for instance (or any other framework for that matter).

Now, I don't really have a clear idea of what still needs to be done, but feel free to add a list of potential work/features that need to land to support this.

cc @alexcrichton @pchickey @sunfishcode

Related discussions: #870

[pepyakin]

Isn't it what similar to what #860 aimed to track ?

UPD: wrong link

[kubkon]

Isn't it what similar to what #860 aimed to track ?

UPD: wrong link

Thanks! That sounds about right! I'll close this issue in favour of the linked one then :-)

[pepyakin]

FWIW, that issue ended up being only about interrupting code, not actual lucet-like stack switching. Therefore, I think this should be reopened.

[pchickey]

For design reference - in Lucet we introduced Vmctx::block_on as the new user-facing primitive for stack switching in an async context. We haven't gotten rid of the lower level yield primitives yet, but block_on is the primitive I wish I could use in wasi-common https://github.com/bytecodealliance/lucet/pull/551

[bkolobara]

I have been working on getting Wasmtime/Wasmer to run on top of Tokio in an actorish environment. I have a few promising prototypes running on top of https://github.com/bkolobara/async-wormhole. In this case only minimal modifications to Wasmtime are needed, async-wormhole takes care of the actual stack switching.