Possibility of non-async support

[philpax]

Hi there!

I recognise that this would be quite difficult to do with the current tooling that Rust provides, but are there any plans to provide a synchronous variant of the preview2 implementation? I'm using WASI in a synchronous / time-boxed environment where the guests don't benefit from async functionality on the host, so I run Wasmtime in sync mode.

For now, I don't need much WASI functionality, so I've replicated the existing interface, made it synchronous, and stubbed out the majority of it - but it would be nice to benefit from the work being done here in future if possible 🙏

[pchickey]

Hi, good question!

The answer right now is I cannot make any promises, but we'll consider it seriously after we get this landed in wasmtime. We have so far avoided keeping parallel sync/async implementations because it gets in the way of iteration as we solve a dozen problems at once. Once we have a solid foundation I hope that the only thing in the way of providing a synchronous variant would be the labor to implement it.

We will need to come up with some sort of analogous hacks used in the wiggle preview1 bindings, and keep host traits factored so that, like in preview1, we can provide either a blocking or async scheduler when constructing the WasiCtx. Since scheduling is finally extensible (via the pollable resource) in preview 2, this is going to be a bit more complex than it was before, but in theory the only blocking call should remain poll_oneoff.

Preview 3 async plans are a whole other can of worms but lets cross that bridge when we get there.

[philpax]

Fantastic, thanks for weighing in! Good to hear that it's being considered - totally understand the problems associated with keeping two implementations. I'm just happy to know I'm not entirely off-base in asking 🙂

[philpax]

For anyone else interested - I have a fork of preview2-prototyping that comments out all the async and replaces the internal awaits with pollster::block_on. I've tried to keep the changes minimal to ensure syncing will be straightforward in future.

This is not at all a robust solution (I certainly wouldn't try running any I/O through this), but it should do the trick for anyone else who just needs to compile WASI components in sync mode: https://github.com/AmbientRun/preview2-prototyping