advance-practice/async

[giscus[bot]]

advance-practice/async

https://course.rs/advance-practice/async.html

[mayfly227]

有点难

[1793523411]

难

[studymachiney]

我是辣鸡

[xiyuan-code]

给你一个赞👍

[zdl361]

"当资源准备好时"，在future中的代码已经返回pendding了，准备资源的代码在哪运行的？

[cyx404]

我也好像知道　😭

[lzh-marble]

文中的例子的话，第一次调用poll，会先spawn一个线程去倒计时，这个线程倒计时结束会调用waker的wake方法，这个线程所进行的操作就是对资源的准备，然后才到下面的if判断返回pending。等到计时结束wake触发后，会重新调用poll，这时会跳到下面的if判断

if Instant::now() >= self.when {
   // 倒计时结束，满足条件到这了
    Poll::Ready(())
} else {
      Poll::Pending
}

[araraloren]

在另一个线程，可以是计时，IO等等 。。

[bxb100]

从 Java await notify 过来...

[showyou2023]

深入本节的代码，就可以写自己的tokio.
如果单纯只是用toki写业务逻辑，是不是无需自己实现poll()。
带有ansync的就是一个可未来执行的future?

[xiyuan-code]

写的真好

内容真丰富

[JiaLiDunGood]

辣鸡 我是辣鸡

[JiaLiDunGood]

脑瓜子嗡嗡的

[zwl773993221]

嗨，咱俩一样

[Ray-lyy]

从第四节还是第五节开始，一直到这儿，属于似是而非的看天书状态了已经

[viciousstar]

没看明白为什么每次Waker都需要更新的原因，如果waker可能失效，那我们传递到别的线程，如计时器线程的waker同样会失效

[lgln0]

waker里面包装了一些执行器的信息，所以每次poll都会生成新的waker。另外，注意到计时器线程中传入的是Arc<Mutex>，和Delay中的waker是共享的，所以能收到waker值的更新

[zdl361]

本例程中是用计时器启动的另一个线程用来唤醒future。真实情况是谁负责唤醒？难道都依赖操作系统的计时服务吗。比如在网络应用中，一堆future都在等待socket接收数据，pending状态的future是静止状态，必须被Poll才会运行。那么谁负责告知future已经有新数据到来？应该是rust的某个组件在处理socket并负责唤醒吧。从socket到future是怎么交接的呢。发自我的手机-------- 原始邮件 --------发件人： marble ***@***.***>日期： 2023年6月8日周四 02:00收件人： sunface/rust-course ***@***.***>抄送： zdl361 ***@***.***>, Comment ***@***.***>主 题： Re: [sunface/rust-course] advance-practice/async (Discussion #1003) 文中的例子的话，第一次调用poll，会先spawn一个线程去倒计时，这个线程倒计时结束会调用waker的wake方法，这个线程所进行的操作就是对资源的准备，然后才到下面的if判断返回pending。等到计时结束wake触发后，会重新调用poll，这时会跳到下面的if判断 if Instant::now() >= self.when { // 倒计时结束，满足条件到这了 Poll::Ready(()) } else { Poll::Pending } —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[sinopec]

脑瓜子嗡嗡的

[zeroonechange]

裂开

[zqlpaopao]

但是简单来看就是：在每次 poll 调用时，都会检查 Context 中提供的 waker 和我们之前记录的 waker 是否匹配。若匹配，就什么都不用做，若不匹配，那之前存储的就必须进行更新。

如果deply一直在poll之前在thread间移动 ，这样不就一直在更新当前wake吗，除非if中的lock作用域是整个函数，不然作用域到了esle的} 之后 下面的可能一直不能被执行

[coolwx]

这几个月一直在做rcore操作系统相关的一些东西，现在回过头来看这一张似乎有点理解。我可以这么理解，poll之所以不采用一个简单的vecdeque，而采用消息队列的缘故就是因为这变相实现了“阻塞机制”。
我们知道在操作系统内核中如果实现阻塞机制，那需要在进程控制块里面加一个阻塞队列，然后把他从进程调度队列中删掉，然后加入到这个阻塞队列中，而在唤醒的时候，就把这个进程控制块重新加到进程调度队列里面。这也就是所谓的“阻塞”是如何具体实现的。
这里用 crossbeam::channel，相当于用这个消息队列，变相实现了操作系统里的“阻塞”操作，我不知道这个理解对不对

[coolwx]

这几个月一直在做rcore操作系统相关的一些东西，现在回过头来看这一张似乎有点理解。我可以这么理解，poll之所以不采用一个简单的vecdeque，而采用消息队列的缘故就是因为这变相实现了“阻塞机制”。
我们知道在操作系统内核中如果实现阻塞机制，那需要在进程控制块里面加一个阻塞队列，然后把他从进程调度队列中删掉，然后加入到这个阻塞队列中，而在唤醒的时候，就把这个进程控制块重新加到进程调度队列里面。这也就是所谓的“阻塞”是如何具体实现的。
这里用 crossbeam::channel，相当于用这个消息队列，变相实现了操作系统里的“阻塞”操作，我不知道这个理解对不对

[4innocent]

咋和 promise A+规范这么像，再想想跟 rxjs 更像了，倒是和 await、notify 不太一样

[ziyoung]

"之前的章节" 对应的链接失效了。

[Justinlaau]

寫得太好了，但是必須先去github 把 mini-tokio 先嘗試消化一篇，再回來看，就會融會貫通

[NickNYU]

和其它语言不同，Rust 中的 Future 不代表一个发生在后台的计算，而是 Future 就代表了计算本身，因此 Future 的所有者有责任去推进该计算过程的执行，例如通过 Future::poll 函数。听上去好像还挺复杂？但是大家不必担心，因为这些都在 Tokio 中帮你自动完成了 :)

这里是不是可以简化为一句话：Rust 原生没有自带Future的运行时，而是交由使用者实现。

感觉很多Rust官方文档都没有说清楚Future、async的机制，我这几天也是反复研究了tokio之后，发现Rust的async只是定义了Compile层面的机制，也就是编译完大概会变成什么样的一个东西。运行时是交由具体使用者实现的。

[peigoz]

后面的更新那里是要确保 future 被新的 task 包裹的时候，后面最内层（最新的） task send 的时候，task 里面的 future 中的 waker 是对应的 当前task 中的 waker。但是这里即使不对应不是也不影响非第一次调用时返回最终的future 的结果吗？不理解更新有什么意义吗

[peigoz]

不同的 waker 调用的不是同一个 future 的 poll 方法吗？如果是那这样 future 的 self.waker 不就不会被重复赋值。最后资源准备完毕调用的 waker 不就还是一开始的？ 😵‍💫