IIS 6.0请求减速(IIS 6.0 requests slowdown)

 为什么你需要停下等待的未来，而不是反复轮询？ 答案很明显，恕我直言。 因为在一天结束时它更快更有效！ 
 
 为了反复轮询未来（可能被称为“ 忙碌等待 ”），图书馆必须决定是经常做还是很少做，而且回答都不令人满意。 经常这样做，你浪费CPU周期，很少做，代码反应迟钝。 
 
 所以是的，你需要在等待某事时停放任务，然后在等待时取消停放任务。 喜欢这个： 
 
#![allow(deprecated)]

extern crate futures;

use std::sync::{Arc, Mutex};
use futures::*;
use futures::task::{park, Task};

struct Status {
    ready: bool,
    task: Option<Task>,
}

#[allow(dead_code)]
struct F(Arc<Mutex<Status>>);

impl Future for F {
    type Item = ();
    type Error = ();

    fn poll(&mut self) -> Result<Async<Self::Item>, Self::Error> {
        println!("Check if flag is set");
        let mut status = self.0.lock().expect("!lock");
        if status.ready {
            Ok(Async::Ready(()))
        } else {
            status.task = Some(park());
            Ok(Async::NotReady)
        }
    }
}

#[test]
fn test() {
    let flag = Arc::new(Mutex::new(Status {
                                       ready: false,
                                       task: None,
                                   }));
    let future = F(flag.clone());
    ::std::thread::spawn(move || {
        ::std::thread::sleep_ms(10);
        println!("set flag");
        let mut status = flag.lock().expect("!lock");
        status.ready = true;
        if let Some(ref task) = status.task {
            task.unpark()
        }
    });
    let result = future.wait();
    println!("result: {:?}", result);
}
 
 请注意， Future::poll在这里做了几件事：它正在检查一个外部条件并且它正在停止任务，因此可以进行比赛 ，例如： 
 
 
 
 poll检查变量并发现它是false ; 
 
 
 外部代码将变量设置为true ; 
 
 
 外部代码检查任务是否停放并发现它不是; 
 
 
 poll了任务，但繁荣！ 现在为时已晚，没有人会再停车了。 
 
 
 为了避免任何比赛，我使用Mutex来同步这些交互。 
 
 PS如果您只需要将一个线程结果包装到Future那么请考虑使用oneshot通道：它具有已实现Future接口的Receiver 。 

Why would you need to park a waiting future instead of polling it repeatedly? The answer is rather obvious, IMHO. Because at the end of the day it's faster and more efficient!
 
To repeatedly poll a future (which might be dubbed "busy-waiting") the library would have to decide whether to do it often or seldom and neither answer is satisfactory. Do it often and you're wasting the CPU cycles, do it seldom and the code is slow to react.
 
So yeah, you need to park the task when you're waiting for something and then unpark it when you've done waiting. Like this:
 
#![allow(deprecated)]

extern crate futures;

use std::sync::{Arc, Mutex};
use futures::*;
use futures::task::{park, Task};

struct Status {
    ready: bool,
    task: Option<Task>,
}

#[allow(dead_code)]
struct F(Arc<Mutex<Status>>);

impl Future for F {
    type Item = ();
    type Error = ();

    fn poll(&mut self) -> Result<Async<Self::Item>, Self::Error> {
        println!("Check if flag is set");
        let mut status = self.0.lock().expect("!lock");
        if status.ready {
            Ok(Async::Ready(()))
        } else {
            status.task = Some(park());
            Ok(Async::NotReady)
        }
    }
}

#[test]
fn test() {
    let flag = Arc::new(Mutex::new(Status {
                                       ready: false,
                                       task: None,
                                   }));
    let future = F(flag.clone());
    ::std::thread::spawn(move || {
        ::std::thread::sleep_ms(10);
        println!("set flag");
        let mut status = flag.lock().expect("!lock");
        status.ready = true;
        if let Some(ref task) = status.task {
            task.unpark()
        }
    });
    let result = future.wait();
    println!("result: {:?}", result);
}
 
Note that Future::poll is doing several things here: it's checking for an external condition and it's parking the task, so it's possible to have a race, like when:
 
 
 
the poll checks the variable and finds it to be false; 
 
 
the outer code sets the variable to true; 
 
 
the outer code checks if the task is parked and finds that it's not; 
 
 
the poll parks the task, but boom! it is too late, nobody is going to unpark it any longer. 
 
 
In order to avoid any races, I've used a Mutex to synchronize these interactions.
 
P.S. If all you need is to wrap a thread result into a Future then consider using the oneshot channel: it has the Receiver that implements the Future interface already.