对这个问题记忆深刻。
的确要一层一层的遍历下去找到当前handle，但是我记得应该可以把handle存起来？
我当时也在想要不要存起来，后来觉得自己没有deep call，遍历更简单就没那么做。

stackless的协程有传染性，整个链上都要是协程，好像还有类型要求。
一个简单但印象深刻的：

int a = co_await return_integer();
std::string s = co_await return_std_string();

int sum = a + std::stoi(s);

...

我记得这两个co_await的协程的返回值类型不同，就不行。






【 在 ensonmj 的大作中提到: 】
: stackless每一次resume都要从top状态一层层遍历下来，不像stackfull直接记录ip，在嵌套比较深的情况下感觉效率有点低。  
: 另外rust的async实现每次resume的时候好像还要copy这个状态机到执行线程站上，那就更慢了。不知道为啥要这么实现
--
FROM 158.140.1.*

组里一位级别最高的哥们，把我们项目里异步框架用 boost.fiber 重写了。

【 在 hgoldfish 的大作中提到: 】
: stackful 协程是指之前 boost 里面实现的 boost.context, boost.fiber 等等协程方案。基本原理是保存寄存器、jmp指令、恢复寄存器。
: 而 stackless 协程是指 c++20 实现的 co_await, co_yield 这个语法。它把协程的代码变换成为另外一段 c++ 的类型，类似于 lambda 那样继承一个专门的协程类型，然后调用它的方法。
: 这里写出了两种协程的对比。
: ...................
--
FROM 163.116.140.*

fiber的运行速度跟屎一样
还真敢用
我们有个feed handler
每秒钟两百万个quote
最开始用fiber
启动就崩
一查内存发现一秒钟几百万个内存申请释放

【 在 softsongs 的大作中提到: 】
: 组里一位级别最高的哥们，把我们项目里异步框架用 boost.fiber 重写了。
:
--
FROM 172.58.235.*

operator + () 里面不是问题。。

我是说要怎么样调用这个 operator+() 才是问题。直接: o1 + o2 是不行的，没有地方放 co_await 这个操作符。

类似的问题 python 和 javascript 都有，所以 python 后面发明了一大堆新的函数，比如 __aenter__(), __aexit__() 之类的，还有 async for 和 async with 这些语法，但 python 还是支持不了 __getitem__(), __add__() 的异步版本。

从这方面来讲，python 比 javascript 还烂，毕竟 javascript 本来就不支持运算符重，而 python 有。

依我看，python 现在非常需要发布一个 py 4.0 版本，去掉 async/await 语法。

【 在 ensonmj 的大作中提到: 】
: 这个语法问题，用rust的语法应该解决：o1.await+o2.await  
--
修改:hgoldfish FROM 110.81.0.*
FROM 110.81.0.*

stackful 协程一般是在创建协程的时候申请内存的啊。如果优化得好的话，前一个协程释放的内存可以给下一个协程使用，应该是反而减少了内存操作，而且因为协程里面运行的函数都可以方便地从栈里面申请内存，应该能够有效地提高内存数据的局部性。

我感觉应该是你们怎么用错了。

【 在 mvtec 的大作中提到: 】
: 所有的async 都有这个尿性
: 必须在内存中创建一个区域，
: 否则你怎么获得执行后的结果
: ...................
--
FROM 110.81.0.*