delay.wit

[pchickey]

Reviewing this proposal, I saw https://github.com/WebAssembly/wasi-i2c/blob/main/wit/delay.wit for the first time.

This duplicates functionality already available through wasi-clocks. wasi:clocks/monotonic-clock.subscribe-duration gives a wasi:io/poll.pollable which becomes ready after a given duration, and the user can call pollable.block to suspend execution until it is ready, or otherwise use wasi:io/poll.poll to multiplex on many pollables.

[Zelzahn]

Thanks for the review! Currently, I have no experience yet with using wasi:clocks, but I'll look into this. Furthermore, I wonder in what capacity it would be possible to maybe change delay.wit to a wrapper around this monotonic clock. This way, the migration cost for compiling current applications to Wasm could be kept to a minimum.

[pchickey]

wit defines an interface, not an implementation, so there is no way to specify that something is a wrapper around another interface.

As we build out the Wasi ecosystem, we don't want to provide competing ways to do the same thing (in this case, suspend execution for some duration), because that makes it unclear to users which is the correct way to go about it. Since clocks and io are already standardized and available in various hosts and worlds, and consumed in various library code (e.g. wasi-libc, rust std, starlingmonkey etc), we don't want to create new worlds where those interfaces aren't available and instead some other interface is used to provide the same functionality - that would require a new target triple for toolchains to select a different implementation, and in general create confusion about what Wasi actually is.

I'm not aware of any technical hurdles for providing an implementation of wasi-io, wasi-clocks, and wasi-i2c in any of the environments listed in the compatibility matrix, so we should move ahead assuming that io and clocks are used, and not specify an alternative. If we encounter some major problems with that approach during the implementation of this proposal, we can revisit that, but I think the burden of showing problems with re-using existing pieces of the wasi ecosystem should be quite high before we create any sort of alternative, due to the ecosystem effects of alternatives to these foundational pieces of our systems.

[sunfishcode]

The current wasi-i2c proposal is focused on synchronous I/O for now, which means it's essentially following the "simple" approach that, when Preview 3 async arives, will become a composable async API as well. The translation of subscribe-duration into Preview 3 async will be just a function that takes a duration and sleeps for that duration, just like the current delay.wit interface. So in a way, the current delay.wit is anticipating Preview 3 😄.

If sleeping via wasi-clocks and wasi-io and pollables are easy to implement in the relevant contexts, then let's use them, but if it's a burden, I don't see it as essential for wasi-i2c to take on here.