为啥 Future::select 会先选择休眠期较长的未来呢？

Posted 2023-03-11

【中文标题】为啥 Future::select 会先选择休眠期较长的未来呢？

【英文标题】：Why does Future::select choose the future with a longer sleep period first?为什么 Future::select 会先选择休眠期较长的未来呢？

【发布时间】：2018-07-22 00:02:43

【问题描述】：

我试图理解Future::select：在这个例子中，首先返回具有较长时间延迟的未来。

当我读到 this article 的例子时，我感到认知失调。作者写道：

select 函数运行两个（如果是 select_all 则更多）期货并返回第一个即将完成的期货。这对于实现超时很有用。

我好像不懂select的意思。

extern crate futures; // v0.1 (old)
extern crate tokio_core;

use std::thread;
use std::time::Duration;
use futures::Async, Future;
use tokio_core::reactor::Core;

struct Timeout 
    time: u32,


impl Timeout 
    fn new(period: u32) -> Timeout 
        Timeout  time: period 
    


impl Future for Timeout 
    type Item = u32;
    type Error = String;

    fn poll(&mut self) -> Result<Async<u32>, Self::Error> 
        thread::sleep(Duration::from_secs(self.time as u64));
        println!("Timeout is done with time .", self.time);
        Ok(Async::Ready(self.time))
    


fn main() 
    let mut reactor = Core::new().unwrap();

    let time_out1 = Timeout::new(5);
    let time_out2 = Timeout::new(1);

    let task = time_out1.select(time_out2);

    let mut reactor = Core::new().unwrap();
    reactor.run(task);

我需要处理时间延迟较小的早期未来，然后处理延迟较长的未来。我该怎么做？

【参考方案1】：

TL;DR：使用tokio::time

如果有一点需要注意：永远不要在异步操作中执行阻塞或长时间运行的操作。

如果您想要超时，请使用来自tokio::time 的内容，例如delay_for 或timeout：

use futures::future::self, Either; // 0.3.1
use std::time::Duration;
use tokio::time; // 0.2.9

#[tokio::main]
async fn main() 
    let time_out1 = time::delay_for(Duration::from_secs(5));
    let time_out2 = time::delay_for(Duration::from_secs(1));

    match future::select(time_out1, time_out2).await 
        Either::Left(_) => println!("Timer 1 finished"),
        Either::Right(_) => println!("Timer 2 finished"),
    

有什么问题？

要理解为什么你会得到你所做的行为，你必须从高层次上理解期货的实现。

当您调用run 时，会有一个循环在传入的future 上调用poll。它循环直到future返回成功或失败，否则future还没有完成。

您对poll 的实现将这个循环“锁定”了5 秒，因为没有任何东西可以中断对sleep 的调用。当睡眠完成时，未来已经准备好，因此选择了未来。

异步超时的实现在概念上是通过在每次轮询时检查时钟来实现的，说明是否已经过了足够的时间。

最大的不同是当一个future返回它还没有准备好时，另一个future可以被检查。这就是select 所做的！

戏剧性的重演：

基于睡眠的定时器

核心：嘿select，你准备好了吗？

选择：嘿future1，你准备好了吗？

future1：坚持一个 seconnnnnnnn [... 5 秒过去 ...] nnnnd。是的！

简单的基于异步的计时器

核心：嘿select，你准备好了吗？

选择：嘿future1，你准备好了吗？

future1：查看手表编号。

选择：嘿future2，你准备好了吗？

future2：查看手表编号。

核心：嘿select，你准备好了吗？

[...轮询继续...]

[... 1 秒过去了...]

核心：嘿select，你准备好了吗？

选择：嘿future1，你准备好了吗？

future1：查看手表编号。

选择：嘿future2，你准备好了吗？

future2：检查手表是的！

这个简单的实现会一遍又一遍地轮询期货，直到它们全部完成。这不是最有效的，也不是大多数执行者所做的。

请参阅How do I execute an async/await function without using any external dependencies? 了解此类执行器的实现。

智能异步定时器

核心：嘿select，你准备好了吗？

选择：嘿future1，你准备好了吗？

future1：检查手表不，但我会在有变化时给你打电话。

选择：嘿future2，你准备好了吗？

future2：检查手表不，但我会在有变化时给你打电话。

[...核心停止轮询...]

[... 1 秒过去了...]

future2：嘿核心，发生了一些变化。

核心：嘿select，你准备好了吗？

选择：嘿future1，你准备好了吗？

future1：查看手表编号。

选择：嘿future2，你准备好了吗？

future2：检查手表是的！

这种更高效的实现在轮询时将 waker 传递给每个未来。当未来还没有准备好时，它会保存那个唤醒器以供以后使用。当某些事情发生变化时，唤醒器会通知执行器的核心，现在是重新检查期货的好时机。这允许执行程序不执行有效的忙等待。

通用解决方案

当您有一个阻塞或长时间运行的操作时，适当的做法是将该工作移出异步循环。有关详细信息和示例，请参阅What is the best approach to encapsulate blocking I/O in future-rs?。

【讨论】：

是否可以使用来自futures_cpupool::CpuPool 的CpuPool 与Timeout 执行相同的操作？

@Sergey 我不确定我是否理解您的问题，但我已尝试回答。

async-based timer的检查率会影响程序的性能吗？如果是，我该如何配置，如果不是，为什么？

@Renkai 一个很好的问题。我的原始故事没有涵盖这一点，但我刚刚添加了一个部分。这有帮助吗？