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