timerfd 是 linux 下才能使用的吧。

太丑了，如果是 C++，对着那个协程抛出异常就行了。但是需要注意整个 C++ 程序都得搞  RAII, 不然会有资源泄露。


【 在 ylh0315 的大作中提到: 】
: 嗯。考虑的过timerfd的方案。主要是得解决一个context同时被两个线程处理的情况。
--
FROM 120.33.8.*

因为你在说纳秒级别 如果kernel by pass只省了纳秒级别 那么用cpu跑交易逻辑是没有意义的 因为随便一个大一些的cache miss或者cpu 切片都比这个大


所有你看见的纳秒级的tick to trade的 都是交易逻辑直接烧在网卡芯片里的


CPU处理交易逻辑的 就算再kernel by pass 也会涉及到硬件中断 甚至就算你的网卡芯片可以by pass cpu直接写内存 你绑交易逻辑的核也需要读内存而不是读缓存 就算读缓存 只要你不是读一级缓存 在现在cpu的构架下 都涉及同步各个核之间的缓存同步



绝大部分墙街的公司 除了真正的几个用fpga的头部玩家 无非都是照猫画虎而已


【 在 mvtec 的大作中提到: 】
: 兄弟厉害一句话就把华尔街这帮trading公司全给否了。 ...
--
FROM 36.28.191.*

交易处理都不需要纳秒级，也不用RTOS。
自动控制系统才需要。
交易系统关注的主要指标是：
并发的客户数，响应时间，秒级，亚秒级。交易吞吐量，TPM，每分钟交易量。
【 在 ziqin 的大作中提到: 】
: 因为你在说纳秒级别 如果kernel by pass只省了纳秒级别 那么用cpu跑交易逻辑是没有意义的 因为随便一个大一些的cache miss或者cpu 切片都比这个大
:
: 所有你看见的纳秒级的tick to trade的 都是交易逻辑直接烧在网卡芯片里的
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*

大家讨论嘛。这贴不是说的协程吗？有说协程怎样用于高频交易的，我就说了这么多。
见谅。
【 在 ziqin 的大作中提到: 】
: 我们在说同一个东西么？做外汇平台的就别在这儿秀了
:  
--
FROM 221.218.61.*

你还是没有看完我所有的描述。epoll已经用了，他是多线程协程的调度核心。
系统设计是依据C10K的理论，关于C10K你可以百度。
上万的客户端，是连接到一个线程池系统，这已经是C10K问题的最高境界了。
在线程池系统，由于长IO占用线程（本来就为数不多）的问题，才用到了协程。
stakfull模式，是因为交易系统存在大量第三方软件，无法控制栈的用量。
而每连接一个协程（CPC)，又重蹈TPC的覆辙，巨额的栈占用。
于是就有了栈池的想法。
这就是我在本帖描述的逻辑线。


几万个客户端，一人一个协程，他们只在活动期间使用栈。所有协程基于一个线程池（多线程协程）进行运作。
线程池的工作线程负责把客户端的请求转发到服务器并将服务器的应答转发回客户端。

采用连接池连接服务器。连接池用来管理多个交易类型（交易路由处理），每个交易类型有多台服务器，形成负载均衡和容错机制。每台服务器有多个连接（多少核就多少连接）。

每个服务器采用TPC模式，每个连接一个线程。由管理器的连接池确定有限的连接数，不直接面对客户。这就规避了TPC的缺点--无限数量的线程导致资源耗尽。资源管理的问题交给交易管理器，服务器就专心致志的做好业务。

而交易管理器控制着整个服务器系统，并使之达到最高系统交易吞吐量。


所有的描述，与本帖的宗旨，完全扣题。

【 在 ziqin 的大作中提到: 】
: 你想要秀 那我就告诉你 你那个构架就是个垃圾 几万个客户端 你一个连接一个线程？就你这个构架 用不用协程都一样 你的瓶颈是在网络io和数据库io上 你在这儿秀协程甚至都不是正确的使用场景
:
: Epoll IOCP直接解决掉你一半以上的问题 然后另一半 你需要把数据库信息内存化 把数据库和内存结构体同步起来 放弃sql查询 直接读内存结构体
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*