Closed codefromthecrypt closed 2 years ago
The most immediate motivation is to have a way to implement a function like poll
, which has a timeout parameter, on top of the canonical-ABI async ABI, where we'll have a wait
function that doesn't have a builtin timeout. The high-level idea is, we create a timer handle, and then we can wait on that and be notified when the timer expires.
My rough idea was that creating a timer would take a snapshot of the current clock value plus the timer duration, and then the wait
implementation could compute a timeout value by subtracting the current clock value. That would support multiple outstanding timers without any invalidating any other. That said, this is just a rough idea at this point.
If you could identify specifically what would be needed for Go's imports for countdowns, I'd be happy to look at whether we can support it here.
I think your description above has the main parts. The main thing I noticed in the ABI missing which is something the go hooks need are identifying a timer by ID (ex starting a timer returns an i32 identifier of the handle), so that it can be canceled.
Handle types in wit are rendered in typical bindings as i32
values. Conceptually, these values are indices into a table of the actual handles. I imagine go can simply use these i32
values for that purpose.
I believe the question here is answered; please reopen or a file a new issue if there are any further questions!
I was looking at the new timer API #12 and wonder the motivation for it. It seems similar, but not quite on what's needed for Go's imports around countdowns. If the design is flexible, it would be neat to be able to use wasi-clocks to implement them https://github.com/golang/go/blob/252324e879e32f948d885f787decf8af06f82be9/misc/wasm/wasm_exec.js#L257-L283