- 主题:stackoverflow 有个比较 c++ stackful 和 stackless 协程的帖子
timerfd 要陷入内核态的。这个方案也太差了吧。一般是 epoll() 那边带一个超时参数搞定。不过新的 uring 好像没超时参数了。
【 在 ylh0315 的大作中提到: 】
: 嗯。说的都是linux。大规模交易系统，WINDOWS太不靠谱了。
--
FROM 183.253.146.*
epoll的超时是整体的超时，管不了个别FD。
【 在 hgoldfish 的大作中提到: 】
: timerfd 要陷入内核态的。这个方案也太差了吧。一般是 epoll() 那边带一个超时参数搞定。不过新的 uring 好像没超时参数了。
:
--
FROM 221.218.61.*
你先算出最近超时的时间，传入那个值。等处理完对应的 fd，再重新算超时时间，重新调用 epoll() 就行了。
【 在 ylh0315 的大作中提到: 】
: epoll的超时是整体的超时，管不了个别FD。
--
FROM 183.253.146.*
是协程不是线程。你好像没看明白这一系列的帖子都是在讲协程。
【 在 ziqin 的大作中提到: 】
: 你想要秀 那我就告诉你 你那个构架就是个垃圾 几万个客户端 你一个连接一个线程？就你这个构架 用不用协程都一样 你的瓶颈是在网络io和数据库io上 你在这儿秀协程甚至都不是正确的使用场景
: Epoll IOCP直接解决掉你一半以上的问题 然后另一半 你需要把数据库信息内存化 把数据库和内存结构体同步起来 放弃sql查询 直接读内存结构体
: 庸人瞎忙
: ...................
--
FROM 183.253.146.*
有什么看不明白的
说了半天就是stackless的协程没法自动保存context
然后又说了半天stack
full的协程stack内存分配有玄学
讲真
这点东西有什么可讨论出来的
标准库的协程这玩意出来才多久
要用要讨论你们也等24的小补丁版出来再讨论
现在真的要用要么就自己每个协程弄个标识
自己heap上弄个内存布局好一点的map查一下
要么最好别用
一来新东西 就不管应用场景一股脑就想用新的 协程有携程的好处 异步回呼有异步回呼的好处 真的每个异步需要高效到保存context用协程嘛？真的有需要用几万个协程的场景么？
协程又不是什么新东西
【 在 hgoldfish 的大作中提到: 】
: 是协程不是线程。你好像没看明白这一系列的帖子都是在讲协程。 ...
--
FROM 36.28.191.*
额～我也不知道为啥 ylh0315 一直在说栈、超时这些协程实现的东东。按说都是已经被研究得差不多的东东了。我感觉很多 C++ 程序员对协程的应用场景仍然不熟悉，而不是协程的实现细节。
协程环境调用第三方库容易阻塞整个线程是个大问题。和 stackless/stackful 没有关系。回调也一样会碰上。
【 在 ziqin 的大作中提到: 】
: 有什么看不明白的
: 说了半天就是stackless的协程没法自动保存context
: 然后又说了半天stack
: ...................
--
修改:hgoldfish FROM 183.253.146.*
FROM 183.253.146.*
里边几百个fd，谁管得了谁呀。
现在就是不指望epoll。也用不了timerfd。
所有的context就是一个数组，由主线程定时检查每个context的超时情况，对超时的context进行标记，根据其状态做出不同的处理。见88楼。
【 在 hgoldfish 的大作中提到: 】
: 你先算出最近超时的时间，传入那个值。等处理完对应的 fd，再重新算超时时间，重新调用 epoll() 就行了。
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
一般协程库要三个部分：
1. 基础的协程切换，一般由语言库(c++ co_await)或者操作系统(swap_context)搞定
2. 事件循环以及协程调度(线程内与线程间调度)
3. 包装 IO 使其协程化。
你缺少的是完整的第二个部分啊。你看一下本版 xmake 的作者的那个 c 协程库处理得很好。C++ 的协程库则比较多，有 libgo, cppcoro 这两个 star 数最多的，libgo 是 oppo 那伙人搞的。
https://github.com/yyzybb537/libgo/blob/master/libgo/routine_sync/timer.h
简单地讲，就是几百个 FD 排个序，看你用 heap 还是 list 都行。然后取第一个 fd 的超时就行了。
我看你还在折腾第一部分，如果是你是 c 程序员，折腾第一部分是正常的，c 程序员总是爱发明底层轮子。但 cpp 程序员的第一部分要么用标准库，要么用 boost::context，别自己折腾了。栈这些东东太底层了。
协程被搞出来已经几十年了。但是一直没有好用的环境。曾经 Python 和 JavaScript 是最接近协程原生语言这个目标的，被两个语言的设计师抄 C# 的 async/await 给搞砸了。
【 在 ylh0315 的大作中提到: 】
: 里边几百个fd，谁管得了谁呀。
--
修改:hgoldfish FROM 183.253.146.*
FROM 183.253.146.*
协程调度就是epoll呀！
主线程创建协程，丢进epoll。所有的线程都在epoll_wait，抓住哪个做哪个协程。协程在yield时，设置epoll，并swapcntext。线程继续epoll_wait。epoll激活这个协程后，由任何一个激活的线程进行resume。
整个的调度过程。
【 在 hgoldfish 的大作中提到: 】
: 一般协程库要三个部分：
: 1. 基础的协程切换，一般由语言库(c++ co_await)或者操作系统(swap_context)搞定
: 2. 事件循环以及协程调度(线程内与线程间调度)
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
你又不是在多个线程间调度协程的超时。
话说，你可以参考一下操作系统的线程调度。因为你现在做的事情，已经相当于在 userland 自行实现了一份操作系统的内核线程调度了。
所以我有个观点是，能够实现协程调度的程序员，也必然有能力实现操作系统内核。
【 在 ylh0315 的大作中提到: 】
: 里边几百个fd，谁管得了谁呀。
: 现在就是不指望epoll。也用不了timerfd。
: 所有的context就是一个数组，由主线程定时检查每个context的超时情况，对超时的context进行标记，根据其状态做出不同的处理。见88楼。
: ...................
--
FROM 183.253.146.*