- 主题:C++的异步模型以后就是sender/receiver这个框架了
c的协程接口，也就是这俩函数了。
【 在 z16166 的大作中提到: 】
: Eric Niebler搞的P2300（std::execution）要在C++26里正式纳入标准。C++20的ranges也是他搞的。
: "泛型函数式组合"是他喜欢的风格
: 英伟达针对P2300的实现stdexec现在风头正劲
: ...................
--
FROM 221.218.61.*
对。
ucontext。在libc里。
以epoll为调度核心，线程池+协程的服务器框架。应用插件只需要使用特定的sender/receiver，就得到有效的异步服务。
就是看起来是同步，实际是异步的那种。
【 在 allegro 的大作中提到: 】
: c的协程吗？
: - 来自 水木社区APP v3.5.7
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*
他已经是最简代码了。没办法比它更快，所有其他协程，包括各种语言的，都是以它为基础，不可能比它快。
getcontext，保存现场到ucontext。
setcontext，从ucontext恢复现场。
swapcontext，＝getcontext＋setcontext，
你说，还怎么提高效率？
至于，把这个低级功能包装成yield，resume，await，wake，，，，
效率高不高，看你的水平了。
【 在 CongHL 的大作中提到: 】
: ucontext性能不行
:
: #发自zSMTH@2106118C
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*
之前有一个说它性能的，是因为里边有一个signal的处理，是一个系统调用，查了一下，这个系统调用不涉及IO，也不涉及锁，应该对性能没大影响。
【 在 CongHL 的大作中提到: 】
: ucontext性能不行
:
: #发自zSMTH@2106118C
--
FROM 221.218.61.*
一些解释型语言，它的现场未必是由通用寄存器构成，可能不需要这种操作，但是性能未必赶得上编译型语言。
【 在 CongHL 的大作中提到: 】
: ucontext性能不行
:
: #发自zSMTH@2106118C
--
FROM 221.218.61.*