- 主题:stackoverflow 有个比较 c++ stackful 和 stackless 协程的帖子
是的，就是由主线程批量处理，为了减小开销，15秒检测一次，精度比较低，但是对于交易来说，够用。这个数可以改。见88楼。
另外，timerfd的方案，一个麻烦是，每个操作正常进行都要想着消掉定时器，这个太麻烦了。
目前的方案是，业务流程只需要设置时间戳和超时值，别的就不用管了。
【 在 wallyz 的大作中提到: 】
: 如果连接（协程）数量很多的话，每个都配一个deadline timer或者steady_timer，代价似乎很大吧
: 其实批量对齐处理足够了，比如100ms或者50ms一次批量对齐处理超时，这样的代价可能是有点协程超时处理稍稍晚了一点点，但对于绝大部分（除了超高实时性要求的）系统来说，精确度已经足够了
: 何况deadline timer本来也不保证能非常精确的返回，有时候会早一点有时候会晚一点
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
需要的不是线程的timeout，是协程的。
【 在 wallyz 的大作中提到: 】
: 每个线程只有一个timerfd，每个timerfd几百毫秒产生一次EPOLLOUT，代价不会很大吧
: 而让epoll带一个小的超时时间提早返回，也一样得从内核态往用户态转，然后还是一样得重新回到epoll wait，
: 让epoll带一个小的超时时间提早返回和用timerfd，好像是个朝三暮四的问题吧
: ...................
--
FROM 221.218.61.*
主要是是资源的快速周转的问题。
前边说过了，采用协程后，单个任务的延时是增加的，但是整体流畅性和吞吐量是增加的。
没有否认asio框架的性能。我说的是，在CPC（每连接一个协程） stackfull模式下，如何解决栈占用空间过大的问题。上万的协程，每个栈2m。一个小小的交易管理器，要买多么大的服务器呢！
【 在 ziqin 的大作中提到: 】
: 每个协程配一个asio deadline timer 不过看他对他那个构架这么津津乐道的样子 估计没用过asio框架
:
: 他这点需求和吞吐量 对asio根本不是个事
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
我这个项目，设计的就是开上万。一个交易管理器的处理上限是60000。
就是C10K问题，一万个客户端。现在不是需要不需要的问题，是怎么对付它的问题。
既然是上万，就得有上万的处理方法。
适合哪个方法，就用哪个方法。
【 在 ziqin 的大作中提到: 】
: 我前面也说了，是不是真的存在需要开几万个协程的场景，还有待商榷
:
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
数据库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.*
确实不知道这玩意儿有啥用。
【 在 hgoldfish 的大作中提到: 】
: 你解释不了 python 里面人人用:
: for i in range(10):
: yield i
: ...................
--
FROM 221.218.61.*
具体这个不懂，i在10的范围内就yield，什么意思？轮询？
谁会调整i？
【 在 hgoldfish 的大作中提到: 】
: 你解释不了 python 里面人人用:
: for i in range(10):
: yield i
: ...................
--
FROM 221.218.61.*
最后一段。
一个协程发一个消息出去，然后等结果就好了。
都是自动处理的。
SendNet();
RecvNet();//里边可能会yield，你不需要管，你也不知道你自己是否是一个协程。只是被告诫，可能是个协程，不要把线程锁跨越之，回来后很可能不是原来的线程了。
够优雅否？
【 在 wallyz 的大作中提到: 】
: 我的朴素理解：
: 协程就是内嵌数据、自带可更新的状态、可根据当前状态和数据恢复/继续执行的一个东西
: 至于是用栈，还是用另外的某种数据结构（比如一个很另类的类）来实现这个东西，理论上都是可以的
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*