summaryrefslogtreecommitdiffstats
path: root/tokio/tests/macros_select.rs
AgeCommit message (Collapse)Author
2020-11-23time: use intrusive lists for timer tracking (#3080)bdonlan
More-or-less a half-rewrite of the current time driver, supporting the use of intrusive futures for timer registration. Fixes: #3028, #3069
2020-10-08time: rename `Delay` future to `Sleep` (#2932)Juan Alvarez
2020-10-08chore: Fix clippy lints (#2931)bdonlan
Closes: #2929 Co-authored-by: Bryan Donlan <bdonlan@amazon.com>
2020-10-01time: introduce `sleep` and `sleep_until` functions (#2826)Juan Alvarez
2020-09-23macros: add #[allow(unused_mut)] to select! (#2858)Alice Ryhl
2020-07-28macros: silence unreachable_code warning in select! (#2678)Blas Rodriguez Irizar
Solves #2665 by adding #[allow(unreachable_code)] inside a branch matching arm. Co-authored-by: Alice Ryhl <alice@ryhl.io>
2020-05-31test: fix all clippy lints in tests (#2573)Mikail Bagishov
2020-01-22Provide `select!` macro (#2152)Carl Lerche
Provides a `select!` macro for concurrently waiting on multiple async expressions. The macro has similar goals and syntax as the one provided by the `futures` crate, but differs significantly in implementation. First, this implementation does not require special traits to be implemented on futures or streams (i.e., no `FuseFuture`). A design goal is to be able to pass a "plain" async fn result into the select! macro. Even without `FuseFuture`, this `select!` implementation is able to handle all cases the `futures::select!` macro can handle. It does this by supporting pre-poll conditions on branches and result pattern matching. For pre-conditions, each branch is able to include a condition that disables the branch if it evaluates to false. This allows the user to guard futures that have already been polled, preventing double polling. Pattern matching can be used to disable streams that complete. A second big difference is the macro is implemented almost entirely as a declarative macro. The biggest advantage to using this strategy is that the user will not need to alter the rustc recursion limit except in the most extreme cases. The resulting future also tends to be smaller in many cases.