- 主题: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.*
ucontext就是汇编代码。
现在唯一的问题是可移植性，例如Intel的CPU与AMD的CPU，通用寄存器是有差异的，它是否都处理好了。
【 在 hgoldfish 的大作中提到: 】
: 你直接 benchmark 一下就知道了。
: 现代 c/c++ 协程库，要么编程语言支持，要么动用汇编才能达到比较好的性能。
:
--
FROM 221.218.61.*
你有benchmark的结果吗？发一个。
【 在 hgoldfish 的大作中提到: 】
: 你直接 benchmark 一下就知道了。
: 现代 c/c++ 协程库，要么编程语言支持，要么动用汇编才能达到比较好的性能。
:
--
FROM 221.218.61.*
嗯。可以推荐一个适配方案。
不错，sender/receiver确实是两个库函数。
通过这两个函数，让应用程序透明的使用协程和异步。
应用程序员完全不知道协程这个东西和异步这个方法。
提供的通讯框架具有多种模式，多进程，多线程，线程池＋协程。这两个函数能够在多种模式下工作，用法完全一样，在这两个函数内部自动判定，是协程环境就异步，否则就同步。
【 在 z16166 的大作中提到: 】
: sender/receiver和C++协程是两个东西，协程是语言机制，Sender/Receiver 是库机制。
: 但通过适配器，可以让 co_await 使用 sender，从而让C++协程用co_await消费 sender 的异步结果。
:
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*
换句话说，把yield和resume封装在这两个函数内，不需要应用程序员关心这些。
跟你说的相反，是这两个函数使用了协程。
【 在 z16166 的大作中提到: 】
: sender/receiver和C++协程是两个东西，协程是语言机制，Sender/Receiver 是库机制。
: 但通过适配器，可以让 co_await 使用 sender，从而让C++协程用co_await消费 sender 的异步结果。
:
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*
性能肯定高不了，问题不在ucontext。
在这两个函数中，yield需要捜索ucontext，线程锁加锁解锁一次，操作epoll一次，调用好几次各种函数，写日志一大堆。
resume需要线程锁加锁解锁一次，写一堆日志。
但是必须这么做，否则，一个任务占死线程，系统吞吐量就完蛋了，总平均等待时间也别看了，这几个线程要为上万任务服务呢。
【 在 hgoldfish 的大作中提到: 】
: 你直接 benchmark 一下就知道了。
: 现代 c/c++ 协程库，要么编程语言支持，要么动用汇编才能达到比较好的性能。
:
--
FROM 221.218.61.*