Attempts to resolve the future to a final value, registering the current task for wakeup if the value is not yet available.
§Return valueThis function returns:
Poll::Pending
if the future is not ready yetPoll::Ready(val)
with the result val
of this future if it finished successfully.Once a future has finished, clients should not poll
it again.
When a future is not ready yet, poll
returns Poll::Pending
and stores a clone of the Waker
copied from the current Context
. This Waker
is then woken once the future can make progress. For example, a future waiting for a socket to become readable would call .clone()
on the Waker
and store it. When a signal arrives elsewhere indicating that the socket is readable, Waker::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 Waker
from the Context
passed to the most recent call should be scheduled to receive a wakeup.
Futures alone are inert; they must be actively poll
ed to make progress, meaning that each time the current task is woken up, it should actively re-poll
pending futures that it still has an interest in.
The 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 poll(2)
or 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 epoll(4)
.
An implementation of poll
should strive to return quickly, and should not 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 a while, the work should be offloaded to a thread pool (or something similar) to ensure that poll
can return quickly.
Once a future has completed (returned Ready
from poll
), calling its poll
method again may panic, block forever, or cause other kinds of problems; the Future
trait places no requirements on the effects of such a call. However, as the poll
method is not marked unsafe
, Rustâs usual rules apply: calls must never cause undefined behavior (memory corruption, incorrect use of unsafe
functions, or the like), regardless of the futureâs state.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4