p3: spec no-op wait-for/wait-until

[rvolosatovs]

Specify that wait-for(0) and wait-until with instants in the past must return immediately.

In Rust that means that these will always return Poll::Ready(()):

• wait_for(0).poll(cx)
• wait_until(now()).poll(cx)

[lann]

always return Poll::Ready(())

Unless there is some hard requirement for this I'm not sure that we should be this strict, for two different reasons:

• It implies that all bindings generators need to provide a way for async functions to explicitly return immediately. I can't think of any examples where this shouldn't be possible but I don't know if we want to commit to it.

• For these functions in particular, it will (probably?) force implementations to poll the clock again, even in situations where this condition is very unlikely. If a caller really needs to not yield on wait_until(now()) it can always do this check itself.

[lann]

Regardless of the above I am in favor of clarifying that wait-for(0) / wait-until(now()) should "not wait"; my question is just whether they should be allowed to yield (return Pending).

[wingo]

If I read https://github.com/WebAssembly/component-model/blob/main/design/mvp/Async.md#async-import-abi correctly, a call to an async function, e.g. monotonic-clock#wait-for(0), may return a 0 in its low bits to indicate that the call hasn't started yet. I am not sure under what circumstances it is allowed for a call to not, you know, call its callee. That would seem to bear on this question.

[sunfishcode]

If polling the clock is slow, one option would be for implementations to remember the last polled value, which would be sufficient for determining whether the application can be aware that a timestamp has happened in the past.