A future represents an asynchronous computation.
A future is a value that may not have finished computing yet. This kind of "asynchronous value" makes it possible for a thread to continue doing useful work while it waits for the value to become available.
The core method of future,
poll, attempts to resolve the future into a
final value. This method does not block if the value is not ready. Instead,
the current task is scheduled to be woken up when it's possible to make
further progress by
polling again. The wake up is performed using
cx.waker(), a handle for waking up the current task.
When using a future, you generally won't call
poll directly, but instead
await! the value.
The result of the
fn poll(self: Pin<&mut Self>, lw: &LocalWaker) -> Poll<Self::Output>
Attempt to resolve the future to a final value, registering the current task for wakeup if the value is not yet available.
This function returns:
Poll::Pendingif the future is not ready yet
Poll::Ready(val)with the result
valof this future if it finished successfully.
Once a future has finished, clients should not
poll it again.
When a future is not ready yet,
stores a clone of the
LocalWaker to be woken once the future can
make progress. For example, a future waiting for a socket to become
readable would call
.clone() on the
LocalWaker and store it.
When a signal arrives elsewhere indicating that the socket is readable,
[LocalWaker::wake] is called and the socket future's task is awoken.
Once a task has been woken up, it should attempt to
poll the future
again, which may or may not produce a final value.
Note that on multiple calls to
poll, only the most recent
LocalWaker passed to
poll should be scheduled to receive a
Futures alone are inert; they must be actively
polled to make
progress, meaning that each time the current task is woken up, it should
poll pending futures that it still has an interest in.
poll function is not called repeatedly in a tight loop-- instead,
it should only be called when the future indicates that it is ready to
make progress (by calling
wake()). If you're familiar with the
select(2) syscalls on Unix it's worth noting that futures
typically do not suffer the same problems of "all wakeups must poll
all events"; they are more like
An implementation of
poll should strive to return quickly, and must
never block. Returning quickly prevents unnecessarily clogging up
threads or event loops. If it is known ahead of time that a call to
poll may end up taking awhile, the work should be offloaded to a
thread pool (or something similar) to ensure that
poll can return
Waker and thread-safety
poll function takes a
LocalWaker, an object which knows how to
awaken the current task.
LocalWaker is not
Sync, so in
order to make thread-safe futures the
should be used to convert the
LocalWaker into a thread-safe version.
LocalWaker::wake implementations have the ability to be more
efficient, however, so when thread safety is not necessary,
LocalWaker should be preferred.
Once a future has completed (returned
then any future calls to
poll may panic, block forever, or otherwise
cause bad behavior. The
Future trait itself provides no guarantees
about the behavior of
poll after a future has completed.