你用得到这个特性么? 还是特别有时间?

【 在 allegro 的大作中提到: 】
: 就是这篇内容：
: https://lewissbaker.github.io/2020/05/11/understanding_symmetric_transfer
: 我是没读明白。
: ...................
--
FROM 142.59.143.*

下个版本很有可能就要把数据路径里所有异步调用转换成Coroutines，所以，是的，还真得了解。


【 在 iFighter 的大作中提到: 】
: 你用得到这个特性么? 还是特别有时间?
:
--
FROM 73.71.157.*

co_return和return的区别

co_return本身还带一个co_wait，导致栈没有被清理

https://lewissbaker.github.io/2018/09/05/understanding-the-promise-type

这个系列是我读过的最好的coroutine系列


【 在 allegro 的大作中提到: 】
: 那个for-loop为啥导致栈溢出能理解吗？
:
--
FROM 115.193.170.*

谢谢! 我目前的理解是:

task foo() {
  co_return;
}

task bar() {
  co_await foo();
}


foo()函数的co_return在foo()的final_suspend这个切换点直接切换到了bar()的执行栈并开始执行.
bar()开始执行后, 当运行完co_wait这一行后,调用foo()返回的task对象的析构函数.
这个析构函数释放了foo()的协程frame和promise对象.

但是当foo()切换回bar()时候,并没有清理栈上foo()的调用frame.
然后当bar()函数析构掉foo()返回的task对象后,这个调用frame就遗漏在栈上了.

直到bar()结束,切换到它的caller,才会将这个遗漏的调用帧忽略.
如果不能及时忽略,比如for-loop的方式调用foo(), 就会爆栈.



如果这样的话这是重大缺陷啊? 这种栈溢出不难复现, 任何协程调用协程都可能出现.
设计coroutine这些大佬们没有一开始就敏锐的发现这里会爆栈吗?


【 在 ziqin 的大作中提到: 】
: co_return和return的区别
: co_return本身还带一个co_wait，导致栈没有被清理
: https://lewissbaker.github.io/2018/09/05/understanding-the-promise-type
: ...................
--
FROM 158.140.1.*

这个优化应该类比的是return value optimization吧，nice to have，真没有也没啥不对

【 在 allegro 的大作中提到: 】
: 谢谢! 我目前的理解是:
:
: task foo() {
: ....................

- 来自「最水木 for iPhone12,8」
--
FROM 172.58.35.*