]> git.lizzy.rs Git - rust.git/blob - library/core/src/future/future.rs
Rollup merge of #90625 - Milo123459:ref-unwind-safe, r=dtolnay
[rust.git] / library / core / src / future / future.rs
1 #![stable(feature = "futures_api", since = "1.36.0")]
2
3 use crate::marker::Unpin;
4 use crate::ops;
5 use crate::pin::Pin;
6 use crate::task::{Context, Poll};
7
8 /// A future represents an asynchronous computation.
9 ///
10 /// A future is a value that might not have finished computing yet. This kind of
11 /// "asynchronous value" makes it possible for a thread to continue doing useful
12 /// work while it waits for the value to become available.
13 ///
14 /// # The `poll` method
15 ///
16 /// The core method of future, `poll`, *attempts* to resolve the future into a
17 /// final value. This method does not block if the value is not ready. Instead,
18 /// the current task is scheduled to be woken up when it's possible to make
19 /// further progress by `poll`ing again. The `context` passed to the `poll`
20 /// method can provide a [`Waker`], which is a handle for waking up the current
21 /// task.
22 ///
23 /// When using a future, you generally won't call `poll` directly, but instead
24 /// `.await` the value.
25 ///
26 /// [`Waker`]: crate::task::Waker
27 #[doc(notable_trait)]
28 #[must_use = "futures do nothing unless you `.await` or poll them"]
29 #[stable(feature = "futures_api", since = "1.36.0")]
30 #[lang = "future_trait"]
31 #[rustc_on_unimplemented(
32     label = "`{Self}` is not a future",
33     message = "`{Self}` is not a future",
34     note = "{Self} must be a future or must implement `IntoFuture` to be awaited"
35 )]
36 pub trait Future {
37     /// The type of value produced on completion.
38     #[stable(feature = "futures_api", since = "1.36.0")]
39     type Output;
40
41     /// Attempt to resolve the future to a final value, registering
42     /// the current task for wakeup if the value is not yet available.
43     ///
44     /// # Return value
45     ///
46     /// This function returns:
47     ///
48     /// - [`Poll::Pending`] if the future is not ready yet
49     /// - [`Poll::Ready(val)`] with the result `val` of this future if it
50     ///   finished successfully.
51     ///
52     /// Once a future has finished, clients should not `poll` it again.
53     ///
54     /// When a future is not ready yet, `poll` returns `Poll::Pending` and
55     /// stores a clone of the [`Waker`] copied from the current [`Context`].
56     /// This [`Waker`] is then woken once the future can make progress.
57     /// For example, a future waiting for a socket to become
58     /// readable would call `.clone()` on the [`Waker`] and store it.
59     /// When a signal arrives elsewhere indicating that the socket is readable,
60     /// [`Waker::wake`] is called and the socket future's task is awoken.
61     /// Once a task has been woken up, it should attempt to `poll` the future
62     /// again, which may or may not produce a final value.
63     ///
64     /// Note that on multiple calls to `poll`, only the [`Waker`] from the
65     /// [`Context`] passed to the most recent call should be scheduled to
66     /// receive a wakeup.
67     ///
68     /// # Runtime characteristics
69     ///
70     /// Futures alone are *inert*; they must be *actively* `poll`ed to make
71     /// progress, meaning that each time the current task is woken up, it should
72     /// actively re-`poll` pending futures that it still has an interest in.
73     ///
74     /// The `poll` function is not called repeatedly in a tight loop -- instead,
75     /// it should only be called when the future indicates that it is ready to
76     /// make progress (by calling `wake()`). If you're familiar with the
77     /// `poll(2)` or `select(2)` syscalls on Unix it's worth noting that futures
78     /// typically do *not* suffer the same problems of "all wakeups must poll
79     /// all events"; they are more like `epoll(4)`.
80     ///
81     /// An implementation of `poll` should strive to return quickly, and should
82     /// not block. Returning quickly prevents unnecessarily clogging up
83     /// threads or event loops. If it is known ahead of time that a call to
84     /// `poll` may end up taking awhile, the work should be offloaded to a
85     /// thread pool (or something similar) to ensure that `poll` can return
86     /// quickly.
87     ///
88     /// # Panics
89     ///
90     /// Once a future has completed (returned `Ready` from `poll`), calling its
91     /// `poll` method again may panic, block forever, or cause other kinds of
92     /// problems; the `Future` trait places no requirements on the effects of
93     /// such a call. However, as the `poll` method is not marked `unsafe`,
94     /// Rust's usual rules apply: calls must never cause undefined behavior
95     /// (memory corruption, incorrect use of `unsafe` functions, or the like),
96     /// regardless of the future's state.
97     ///
98     /// [`Poll::Ready(val)`]: Poll::Ready
99     /// [`Waker`]: crate::task::Waker
100     /// [`Waker::wake`]: crate::task::Waker::wake
101     #[lang = "poll"]
102     #[stable(feature = "futures_api", since = "1.36.0")]
103     fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
104 }
105
106 #[stable(feature = "futures_api", since = "1.36.0")]
107 impl<F: ?Sized + Future + Unpin> Future for &mut F {
108     type Output = F::Output;
109
110     fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
111         F::poll(Pin::new(&mut **self), cx)
112     }
113 }
114
115 #[stable(feature = "futures_api", since = "1.36.0")]
116 impl<P> Future for Pin<P>
117 where
118     P: ops::DerefMut<Target: Future>,
119 {
120     type Output = <<P as ops::Deref>::Target as Future>::Output;
121
122     fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
123         <P::Target as Future>::poll(self.as_deref_mut(), cx)
124     }
125 }