In referencing the module-level async implementation for #12973, I matched the existing behavior for the waker. wasmtime_call_future_poll passes Waker::noop() when polling the underlying Rust future, so there's no way for the caller to know when the future is ready to make progress.
For our use case this is worth adding. We're hosting components from Python via wasmtime-py and need to integrate with asyncio's event loop. Without a waker, the only option is busy-polling with asyncio.sleep(0). The same problem would apply to any language binding that integrates with a cooperative event loop.
Adding a nullable waker parameter to the existing wasmtime_call_future_poll (NULL = Waker::noop(), same behavior as today) would be an ABI break but not a behavioral one. There's no meaningful performance advantage to omitting the waker as tight polling loops would simply pass NULL. A new function like wasmtime_call_future_poll_with_waker would avoid the ABI break entirely.
In referencing the module-level async implementation for #12973, I matched the existing behavior for the waker. wasmtime_call_future_poll passes Waker::noop() when polling the underlying Rust future, so there's no way for the caller to know when the future is ready to make progress.
For our use case this is worth adding. We're hosting components from Python via wasmtime-py and need to integrate with asyncio's event loop. Without a waker, the only option is busy-polling with asyncio.sleep(0). The same problem would apply to any language binding that integrates with a cooperative event loop.
Adding a nullable waker parameter to the existing wasmtime_call_future_poll (NULL = Waker::noop(), same behavior as today) would be an ABI break but not a behavioral one. There's no meaningful performance advantage to omitting the waker as tight polling loops would simply pass NULL. A new function like wasmtime_call_future_poll_with_waker would avoid the ABI break entirely.