需要的不是线程的timeout，是协程的。
【 在 wallyz 的大作中提到: 】
: 每个线程只有一个timerfd，每个timerfd几百毫秒产生一次EPOLLOUT，代价不会很大吧
: 而让epoll带一个小的超时时间提早返回，也一样得从内核态往用户态转，然后还是一样得重新回到epoll wait，
: 让epoll带一个小的超时时间提早返回和用timerfd，好像是个朝三暮四的问题吧
: ...................
--
FROM 221.218.61.*

我前面也说了，是不是真的存在需要开几万个协程的场景，还有待商榷



【 在 ylh0315 的大作中提到: 】
: 主要是是资源的快速周转的问题。
: 前边说过了，采用协程后，单个任务的延时是增加的，但是整体流畅性和吞吐量是增加的。
: 没有否认asio框架的性能。我说的是，在CPC（每连接一个协程）  stackfull模式下，如何解决栈占用空间过大的问题。上万的协程，每个栈2m。一个小小的交易管理器，要买多么大的服务器呢！
: ...................
--
FROM 183.128.163.*

随便弄个 c10k，就开几万个协程了。一个协程处理一条连接。

而且我很喜欢在协程里面管理一系列对象的生命周期。所有的对象都申请在协程栈里面，协程退出的时候一次性全都销毁掉，不要在堆里面搞来搞去。

【 在 ziqin 的大作中提到: 】
: 我前面也说了，是不是真的存在需要开几万个协程的场景，还有待商榷
--
FROM 120.33.8.*

数据库io是在服务器上，不是在交易管理器上。
它很难异步化，一般就不管了，当然谁有好办法还是可以说说。所以不是无脑协程，这个部分基本用不到协程。
交易管理器，几乎是纯io。在我的系统里，转发一个完整的交易需要4次加密解密，压缩解压缩。就是这点事导致的延时。
它关心的就是资源周转，尤其是服务器，服务完一个交易，立即进行下一个，就像银行窗口。所以排队叫号机一定要响应及时。把服务器的交易吞吐量调度满。
服务器不需要C10K，它只需要发挥最高的处理能力，一般线程数保持核数，或多一点点。如果吞吐量不够，可以增加服务器的数量。

C10K只出现在交易管理器。10000个用户在这里排队等候使用服务器资源。哪一个协程需要等待IO了，就立即yield，把线程让出来，让它赶紧处理其他任务。
【 在 ziqin 的大作中提到: 】
: 所以你的意思是，因为懒得管理资源生命周期，所以一股脑干脆直接用协程
: 这不是滥用又是什么
: 协程这种模式，不是为了给你简化资源的管理的，而是为了在某些真的需要很高性能但又不得不异步的情况下采用的，省的就是user层面的资源存取和context资源存取的速度。
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*

不是为了进行异步IO同步使用，就没必要使用协程。
【 在 hgoldfish 的大作中提到: 】
: 协程就是有这个妙用。很少有人注意到协程是可以用于管理对象生命周期的。
: 这东西现在很少有人这么用：一是主流语言的协程使用都很不方便，除了 go 把协程作为语言核心特性，其它语言都把协程做成锦上添花的东西。而 golang 的协程被包装过，应该叫 CSP，类似于 ACTOR，不是简单的协程。二是主流语言只有 C++ 才搞手动的内存资源管理，犯不着折腾这事。
: 协程是超轻量的，创建一个协程基本就是一条 mmap() 调用而已。滥用又怎么样呢。而且你这里注意，mmap() 本身就是一种内存管理。把协程看作是一种新型的内存管理方式是合情合理的。
: ...................
--
FROM 221.218.61.*