- 主题:C++的异步模型以后就是sender/receiver这个框架了
ucontext就是汇编代码。
现在唯一的问题是可移植性,例如Intel的CPU与AMD的CPU,通用寄存器是有差异的,它是否都处理好了。
【 在 hgoldfish 的大作中提到: 】
: 你直接 benchmark 一下就知道了。
: 现代 c/c++ 协程库,要么编程语言支持,要么动用汇编才能达到比较好的性能。
:
--
FROM 221.218.61.*
你有benchmark的结果吗?发一个。
【 在 hgoldfish 的大作中提到: 】
: 你直接 benchmark 一下就知道了。
: 现代 c/c++ 协程库,要么编程语言支持,要么动用汇编才能达到比较好的性能。
:
--
FROM 221.218.61.*
libunifex被libstdexec打败了
【 在 overcomeunic 的大作中提到: 】
: 的确,libunifex我还没有看呢,libunifex看着很久没有更新了,folly还是持续更新
--
FROM 123.115.134.*
sender/receiver和C++协程是两个东西,协程是语言机制,Sender/Receiver 是库机制。
但通过适配器,可以让 co_await 使用 sender,从而让C++协程用co_await消费 sender 的异步结果。
【 在 ylh1969 的大作中提到: 】
: c的协程接口,也就是这俩函数了。
--
FROM 123.115.134.*
嗯。可以推荐一个适配方案。
不错,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.*
sender/receiver可不是两个库函数啊
【 在 ylh1969 的大作中提到: 】
: 嗯。可以推荐一个适配方案。
: 不错,sender/receiver确实是两个库函数。
: 通过这两个函数,让应用程序透明的使用协程和异步。
: ...................
--
FROM 123.115.134.*
纤切换是纤程切换。事件循环是事件循环。
你一直把两个事情给混起来。
【 在 ylh1969 的大作中提到: 】
: 性能肯定高不了,问题不在ucontext。
: 在这两个函数中,yield需要捜索ucontext,线程锁加锁解锁一次,操作epoll一次,调用好几次各种函数,写日志一大堆。
: resume需要线程锁加锁解锁一次,写一堆日志。
: ...................
--
FROM 120.37.20.*
我的是。
【 在 z16166 的大作中提到: 】
: sender/receiver可不是两个库函数啊
:
--
FROM 221.218.61.*