Stream: git-wasmtime

Topic: wasmtime / issue #14364 Higher resolution for monotonic-c...

Wasmtime GitHub notifications bot (Sep 20 2026 at 18:04):

Destructor17 opened issue #14364:

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 1ms resolution 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.

Wasmtime GitHub notifications bot (Sep 20 2026 at 18:09):

Destructor17 edited issue #14364:

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.

Wasmtime GitHub notifications bot (Sep 21 2026 at 10:47):

Destructor17 edited issue #14364:

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.

Wasmtime GitHub notifications bot (Sep 21 2026 at 17:34):

alexcrichton added the wasi:impl label to Issue #14364.

Wasmtime GitHub notifications bot (Sep 21 2026 at 17:35):

alexcrichton commented on issue #14364:

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.

Wasmtime GitHub notifications bot (Sep 24 2026 at 16:27):

fitzgen added the enhancement label to Issue #14364.

Last updated: Oct 11 2026 at 04:10 UTC