- 主题:stackoverflow 有个比较 c++ stackful 和 stackless 协程的帖子
你先算出最近超时的时间，传入那个值。等处理完对应的 fd，再重新算超时时间，重新调用 epoll() 就行了。
【 在 ylh0315 的大作中提到: 】
: epoll的超时是整体的超时，管不了个别FD。
--
FROM 183.253.146.*
是协程不是线程。你好像没看明白这一系列的帖子都是在讲协程。
【 在 ziqin 的大作中提到: 】
: 你想要秀 那我就告诉你 你那个构架就是个垃圾 几万个客户端 你一个连接一个线程？就你这个构架 用不用协程都一样 你的瓶颈是在网络io和数据库io上 你在这儿秀协程甚至都不是正确的使用场景
: Epoll IOCP直接解决掉你一半以上的问题 然后另一半 你需要把数据库信息内存化 把数据库和内存结构体同步起来 放弃sql查询 直接读内存结构体
: 庸人瞎忙
: ...................
--
FROM 183.253.146.*
额～我也不知道为啥 ylh0315 一直在说栈、超时这些协程实现的东东。按说都是已经被研究得差不多的东东了。我感觉很多 C++ 程序员对协程的应用场景仍然不熟悉，而不是协程的实现细节。
协程环境调用第三方库容易阻塞整个线程是个大问题。和 stackless/stackful 没有关系。回调也一样会碰上。
【 在 ziqin 的大作中提到: 】
: 有什么看不明白的
: 说了半天就是stackless的协程没法自动保存context
: 然后又说了半天stack
: ...................
--
修改:hgoldfish FROM 183.253.146.*
FROM 183.253.146.*
一般协程库要三个部分：
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.*
你又不是在多个线程间调度协程的超时。
话说，你可以参考一下操作系统的线程调度。因为你现在做的事情，已经相当于在 userland 自行实现了一份操作系统的内核线程调度了。
所以我有个观点是，能够实现协程调度的程序员，也必然有能力实现操作系统内核。
【 在 ylh0315 的大作中提到: 】
: 里边几百个fd，谁管得了谁呀。
: 现在就是不指望epoll。也用不了timerfd。
: 所有的context就是一个数组，由主线程定时检查每个context的超时情况，对超时的context进行标记，根据其状态做出不同的处理。见88楼。
: ...................
--
FROM 183.253.146.*
没这么简单哦。。你可以参考一下 libgo 和 cppcoro 啊。看看它们是怎么实现协程版本的 mutex, timer 等等的。
【 在 ylh0315 的大作中提到: 】
: 协程调度就是epoll呀！
: 主线程创建协程，丢进epoll。所有的线程都在epoll_wait，抓住哪个做哪个协程。协程在yield时，设置epoll，并swapcntext。epoll激活这个协程后，由一个线程进行resume。
: 整个的调度过程。
: ...................
--
FROM 183.253.146.*
Windows 和 C# 都是好东东。本青经常吹爆 win32api，可惜都是巨硬家的。那就没办法了。业界也是一样，不爱用巨硬家的。被坑怕了。
【 在 leadu 的大作中提到: 】
: 不参与你们对协程的讨论，太蠢了
: 如果一个系统可以上通用os，windows有rio，intel抄了个半成品是dpdk，linux不会表现的比windows更好。
: 除非你裁剪linux内核，但都到了要裁剪内核的地步，我为啥不写点verilog直接fpga甚至asic搞定？
: ...................
--
修改:hgoldfish FROM 120.33.8.*
FROM 120.33.8.*
随便弄个 c10k，就开几万个协程了。一个协程处理一条连接。
而且我很喜欢在协程里面管理一系列对象的生命周期。所有的对象都申请在协程栈里面，协程退出的时候一次性全都销毁掉，不要在堆里面搞来搞去。
【 在 ziqin 的大作中提到: 】
: 我前面也说了，是不是真的存在需要开几万个协程的场景，还有待商榷
--
FROM 120.33.8.*
协程就是有这个妙用。很少有人注意到协程是可以用于管理对象生命周期的。
这东西现在很少有人这么用：一是主流语言的协程使用都很不方便，除了 go 把协程作为语言核心特性，其它语言都把协程做成锦上添花的东西。而 golang 的协程被包装过，应该叫 CSP，类似于 ACTOR，不是简单的协程。二是主流语言只有 C++ 才搞手动的内存资源管理，犯不着折腾这事。
协程是超轻量的，创建一个协程基本就是一条 mmap() 调用而已。滥用又怎么样呢。而且你这里注意，mmap() 本身就是一种内存管理。把协程看作是一种新型的内存管理方式是合情合理的。
【 在 ziqin 的大作中提到: 】
: 所以你的意思是，因为懒得管理资源生命周期，所以一股脑干脆直接用协程
: 这不是滥用又是什么
: 协程这种模式，不是为了给你简化资源的管理的，而是为了在某些真的需要很高性能但又不得不异步的情况下采用的，省的就是user层面的资源存取和context资源存取的速度。
: ...................
--
FROM 47.243.39.*
你解释不了 python 里面人人用:
for i in range(10):
yield i
这个也是协程，只不过叫做非对称协程。
【 在 ylh0315 的大作中提到: 】
: 不是为了进行异步IO同步使用，就没必要使用协程。
: 事。
--
FROM 110.81.0.*