@@ -4,7 +4,8 @@ use crate::ops;
44use crate :: pin:: Pin ;
55use crate :: task:: { Context , Poll } ;
66
7- /// A future represents an asynchronous computation obtained by use of [`async`].
7+ /// A future represents an asynchronous computation, commonly obtained by use of
8+ /// [`async`].
89///
910/// A future is a value that might not have finished computing yet. This kind of
1011/// "asynchronous value" makes it possible for a thread to continue doing useful
@@ -68,13 +69,21 @@ pub trait Future {
6869 ///
6970 /// # Runtime characteristics
7071 ///
71- /// Futures alone are *inert*; they must be *actively* `poll`ed to make
72- /// progress, meaning that each time the current task is woken up, it should
73- /// actively re-`poll` pending futures that it still has an interest in.
72+ /// Futures alone are *inert*; they must be *actively* `poll`ed for the
73+ /// underlying computation to make progress, meaning that each time the
74+ /// current task is woken up, it should actively re-`poll` pending futures
75+ /// that it still has an interest in.
7476 ///
75- /// The `poll` function is not called repeatedly in a tight loop -- instead,
76- /// it should only be called when the future indicates that it is ready to
77- /// make progress (by calling `wake()`). If you're familiar with the
77+ /// Having said that, some Futures may represent a value that is being
78+ /// computed in a different task. In this case, the future's underlying
79+ /// computation is simply acting as a conduit for a value being computed
80+ /// by that other task, which will proceed independently of the Future.
81+ /// Futures of this kind are typically obtained when spawning a new task into an
82+ /// async runtime.
83+ ///
84+ /// The `poll` function should not be called repeatedly in a tight loop --
85+ /// instead, it should only be called when the future indicates that it is
86+ /// ready to make progress (by calling `wake()`). If you're familiar with the
7887 /// `poll(2)` or `select(2)` syscalls on Unix it's worth noting that futures
7988 /// typically do *not* suffer the same problems of "all wakeups must poll
8089 /// all events"; they are more like `epoll(4)`.
0 commit comments