不是有吗？tokio-cron- scheduler

我的理解，这里必须在判断pending的时候把future放回，因为此时waker通过Arc保存了一份Task引用，如果不放回的话，在调用wake的时候会找不到之前的task信息。

前面需要take()，获取到future才能poll，future没有完成，就要放回去。当future完成了，触发waker，wake的时候会将task再次发送到channel，这时候executor再次收到task，再去poll future，future不是pending了，就不再放回task。

大佬们 有个问题呀 不是很能理解，啥时候在第二次poll的时候把task又放回channel了？感觉没有这个体现并且 wake函数也没有看到往channel里发送的task的迹象呀？

大佬们 有个问题呀 不是很能理解，啥时候在第二次poll的时候把task又放回channel了？感觉没有这个体现并且 wake函数也没有看到往channel里发送的task的迹象呀？

@TsGanT 通过实现ArcWake，然后内部调用wake函数的时候会调用ArcWake::wake_by_ref，这个时候发送的task

我觉得作者的注释

                // Future还没执行完，因此将它放回任务中，等待下次被poll

放在那里有点问题

      if let Some(waker) = shared_state.waker.take() {
        waker.wake();
      }

在这里调用了 wake 后， 会触发

    fn wake_by_ref(arc_self: &Arc<Self>) {
        // 通过发送任务到任务管道的方式来实现`wake`，这样`wake`后，任务就能被执行器`poll`
        let cloned = arc_self.clone();
        arc_self
            .task_sender
            .send(cloned)
            .expect("任务队列已满");
    }

这样才能重新入对

let (task_sender, ready_queue) = sync_channel(MAX_QUEUED_TASKS);
我好像知道啦, 他俩是一对儿~

然后在
···
fn poll(self: Pin<&mut Self>, cx: &mut Context<'>) -> PollSelf::Output {
···
后面加上
···
fn poll(self: Pin<&mut Self>, cx: &mut Context<'>) -> PollSelf::Output {
println!("i am running");
···
再次执行，感觉就比较明白了

这里是两个 Future 组合，然后底层涉及 Waker 的注册，我还在看这一部分，但是做来组合 Future 的案例还不错。

相关的文章：https://zhuanlan.zhihu.com/p/66028983

async里面没有await，那你写的async没有任何意义。只不过async这个整体作为一个future，但是在async内部运行时是不会产生任何调度的。

梳理了下整个executor TimerFuture的流程：
1.executor run推出async，poll执行async同步代码，输出howdy
2.executor run poll内继续执行，遇到TimerFuture，执行TimerFuture poll，返回pending状态
3.TimerFuture执行完毕，awake唤醒executor run，再次执行executor run poll，然后进入TimerFuture poll
4.TimerFuture poll直接返回ready状态，executor run poll得以继续async内await下面的代码，输出done
5.输出done后，此时executor run poll才算执行完毕，返回ready状态，完成

总结一下几个要点：

1. async作为一个future，每次poll遇到await停止，进入await方法里的poll
2. await方法内awake唤醒的是上层调度逻辑，而不是await方法本身
3. 唤醒调度逻辑后会继续在上层调度逻辑进行poll，然后再次进入await方法里的poll直到该await方法ready
4. 当检测到await方法ready，那么该await方法就相当于poll内的同步代码了，直接往下走

再次总结一下async内碰到await的逻辑：

1. async碰到await，会沉入到await方法内的poll
2. await poll pending，那么记录当前future，等待唤醒
3. await poll ready，则await执行完毕，继续同步代码直到再次await

这只是根据这个例子总结的机制，至于rust内部是否是这样的，还需再了解，持续学习。

简单来说就是Task被轮询为Pending的时候会变成自引用结构，防止被Drop。同时Task持有Channel的发送端，这样Executor的接收端也不会被Drop，上面的第二个例子中因为Task无法被再次wake，所以task handle end之后就会一直block住。

谢谢回复，但是我把自引用和 future_slot.take() 中 take 出 future 的情况都算进去了，最后结果是 task.strong_count = 1... 是不是什么地方多算了...

谢谢，终于弄懂了，我的确漏了 waker.wake() 这块没算进去，waker会被 wake 消费掉，导致task的count被-1了

Executor轮询时如果Task中的future是Pending的，那么Executor会把被take出来的future放回Task。

个人理解，不对的请见谅并请指正。

context在第一次async块poll的时候，应该是已经可以被块内访问了，那么子future在poll的时候也就能使用了

use std::ptr::null_mut;

struct P {
    val: usize,
    ptr: *mut usize,
}

impl P {
    fn new(val: usize) -> P {
        P {
            val,
            ptr: null_mut(),
        }
    }

    fn init_ptr(&mut self) {
        self.ptr = &mut self.val as *mut usize;
    }
}

#[cfg(test)]
mod tests {
    use std::mem::swap;
    use crate::pin_demo::pin_demo3::P;

    #[test]
    fn test() {
        let mut p1 = P::new(1);
        let mut p2 = P::new(2);

        // 初始化p1,p2内部裸指针
        p1.init_ptr();
        p2.init_ptr();

        // 交换 p1，p2 对应的栈内存
        swap(&mut p1, &mut p2);

        // 获取 p2 裸指针对应的实际值
        let p2_val = unsafe { *(p2.ptr) };

        // p1的val 和 p2裸指针对应的是一个值
        assert_eq!(p1.val, p2_val);
    }
}

使用PIN能够固定自引用的数据类型的值，如p1,p2 让值保持一个不变的内存地址

首先需要指出，Pin 本身不是一个 trait，而是一个 struct，只能包裹一个（智能）指针 P。所以我们严格说要写成 Pin<P> 的样子，Pin，例如 Pin 是没有意义的。最常见的就是 Pin<&T> 或者 Pin<&mut T>。

其次，Pin 一定程度上只是提供了个编译器层面的约束，阻止暴露 T （都 tm 直接暴露数据本体了随随便便被 move 掉）或者 &mut T（std::mem::swap 之类的内存操作也能把 T 拿走）进而防止指针 P 指向的 T 被移动。如果 unsafe 满天飞也是可能形同虚设的，不过非高级开发者一般只考虑 safe Rust。

再有，谈谈 Pin 的用武之地，其中最主要的就是 async Rust。
本文的内容解释了 Future 为什么不能被 move 的，用 Rust 的语言表达就是实现了 !Unpin 这个 trait。需要提一下的是，Rust 的世界绝大多数类型都是自动实现 Unpin 的（auto trait），毕竟大多数时候我们不关心是否需要移动 T。但是，在一些情况下，如 tokio::select! 去同时执行多个 Future，有可能移动之，所以传入的 Future （后面以F 代称）必须是 Unpin 的。咋办？拿 Pin 钉住咯。结合前面提到的只能 Pin 一个指针，我们 Pin 一下 &mut F 不就可以咯！所以就有了 tokio::pin! 这个宏，如：

// ...
let mut f = async fn {
    // ...
};
tokio::pin!(f);
// ...

本质就是变量遮蔽一下, 不需要你写个 unsafe 而已：

// ...
let mut f = async fn {
    // ...
};
let mut f = unsafe {
    std::pin::Pin::new_uncheck(&mut f)
}
// ...

个人结合各类教程和源代码阅读产出见解，或者说总结，请批评指正。强烈推荐各位仔细研读 https://folyd.com/blog/rust-pin-advanced，对 Pin 的介绍总结是相当详尽，而且难能可贵，是中文的！

异步放在哪个语言都是相当麻烦的，cpp 本来就地狱难度，遇到异步老鸟也得踮着脚过河，一不小心就出问题。go 广受好评就是相当强大的开箱即用的 goroutine 协程，等于是语言帮你处理了各种细节。Rust 在尽最大努力确保内存安全的前提下提供最大的自由，算是折中方案？

总之这块算是深水区，还是得多看源码，多写项目，出问题去分析解决问题，进步会更快。

同感，应该在 poll 第一次被执行时触发

启动一个新线程是为了创建一个 Waker ，通过使新线程睡眠实现定时，然后调用wake 方法唤醒一个挂起的 Task

这里是在模拟”异步“，你可以想象这个线程就像是正在io，过一段时间才会完成，然后触发waker去告诉executor可以poll我了（实际上wake的时候触发了task将自己发送给executor）。

但是我有个问题，那就是这个生成的线程为啥不是在new的时候就直接开始执行，而是到了poll的时候才开始执行这个线程中的内容呢？

new 的时候定时器就开始计时了，执行到 await 时去执行poll方法去判断一次到时间没，并注册唤醒函数

比如：
当执行器调用一个Future的poll方法，若在这次 poll 中， Future 可以被完成，则会返回 Poll::Ready(result)给执行器 ，反之则返回 Poll::Pending给执行器以便他未来继续poll这个Future， Pending时Future会记录下执行器调用poll时传入的wake（）函数指针，当未来 Future 准备好进一步执行时， Future会调用wake（）通知执行器继续poll这个Future，然后管理该 Future 的执行器(例如上一章节中的block_on函数)会再次调用 poll 方法，此时 Future 就可以继续执行了。直至Future返回Poll::Ready（ready）完成。

执行器                                                Future
调用Future::Pool执行某个未完成的Future                     
                                                           Future::pool执行，如果完成则返回Ready给执行器
收到Ready返回值，确认这个Future已经完成
                                                           Future::pool执行，如果未完成，则记录执行器的wake函 
                                                           数指针，以便通知执行器未来自己可以继续，并返回 
                                                           Pending给执行器
收到Pending返回值，下次pool继续这个Future
                                                           Future可以继续执行，调用wake通知执行去可以继续
调用Future::poll
重复……

最外面这个async块应该是生成了一个状态机Future

    spawner.spawn(async {
        println!("开始！");
        // 创建定时器Future，并等待它完成
        TimerFuture::new(Duration::new(2, 0)).await;
        println!("完成！");
    });

这个Future会match当前的状态来决定执行到哪里

那么问题来了，没用过 c艹 的人咋办🌚

看代码像是把队列里的future取出来，poll一次之后看还是不是pending(),如果是就把原本在队列的future覆盖掉

应该就是执行器一直检查队头