Higher resolution for monotonic-clock.wait-*

[Destructor17]

Feature

monotonic-clock.wait-until and monotonic-clock.wait-for in WASIp3 (and probably corresponding pollables in WASIp2) are implemented using tokio::time::sleep, which is kinda inaccurate in terms of waiting. It seem to have 1ms resolution on UNIX and up to ~16ms on Windows. It would be nice to have a higher-resolution sleep primitive.

Benefit

It's not observable on workloads Wasmtime is usually used for, but such inaccuracy has high impact on GUI apps if sleep between frames is implemented in guest code. In my case it makes FPS drop from 60 to 58 on UNIX and to 30 on Windows.

Implementation

This can be solved by simply using tokio_hrtime, a drop-in replacement for tokio::time.

Alternatives

Well, tokio_hrtime is just the first thing that pops up while googling. Have not researched this topic in-depth, but there should be more implementations, although tokio_hrtime works fine for me.

As for Windows, this problem can also be (partially) solved by calling timeBeginPeriod function to increase resolution to 1ms, but they say it makes Windows waste CPU cycles.

Update:
Another alternative is just allowing embedder to override asynchronous wait for WASIp3 by watever-they-want. Overriding it for WASIp2 also seem to be possible.

[alexcrichton]

Thanks for the report! FWIW with Linker::allow_shadowing it should be possible to swap in your own implementation of wasi:clocks for wasip2/wasip3. If you're using the wasmtime CLI, however, that'll not work there.