You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this commit introduces a new method to
`tokio::sync::oneshot::Receiver<T>`.
broadly speaking, users of the oneshot channel are encouraged to
`.await` the `Receiver<T>` directly, as it will only yield a single
value.
users implementing their own `std::future::Future`s directly may instead
poll the receiver via
`<Receiver<T> as Future<Output = Result<T, RecvError>::poll(..)`.
note that the contract of `Future::poll()` states that clients should
not poll a future after it has yielded `Poll::Ready(value)`.
this commit provides a way to inspect the
state of a receiver, to avoid violating the contact of
`Future::poll(..)`, or requiring that a oneshot channel users track this
state themselves externally via mechanisms like
`futures::future::FusedFuture`, or wrapping the receiver in an
`Option<T>`.
NB: this makes a small behavioral change to the implementation of
`<Receiver<T> as Future<Output = Result<T, RecvError>::poll(..)`. this
change is acceptable, per the `Future::poll()` documentation regarding
panics:
> 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.
the upside of this is that it means a broken or closed channel, e.g.
when the sender is dropped, will settle as "finished" after it yields an
error.
see:
* tokio-rs#7137 (comment)
* https://doc.rust-lang.org/stable/std/future/trait.Future.html#panics
Signed-off-by: katelyn martin <[email protected]>
0 commit comments