- 主题:stackoverflow 有个比较 c++ stackful 和 stackless 协程的帖子
不懂那么多理论。实际上大规模交易系统基本都是UNIX/LINUX。比较稳定可靠。WINDOWS?经常不稳定,也可能是用的不好。
【 在 leadu 的大作中提到: 】
: 不参与你们对协程的讨论,太蠢了
: 如果一个系统可以上通用os,windows有rio,intel抄了个半成品是dpdk,linux不会表现的比windows更好。
: 除非你裁剪linux内核,但都到了要裁剪内核的地步,我为啥不写点verilog直接fpga甚至asic搞定?
: ...................
--
FROM 221.218.61.*
linux是因为免费吧。在异步方面windows的iocp比epoll还是nb一点的,io_uring 的生态还差得远
【 在 ylh0315 (ylh0315) 的大作中提到: 】
: 不懂那么多理论。实际上大规模交易系统基本都是UNIX/LINUX。比较稳定可靠。WINDOWS?经常不稳定,也可能是用的不好。
: 【 在 leadu 的大作中提到: 】
: : 不参与你们对协程的讨论,太蠢了
: : 如果一个系统可以上通用os,windows有rio,intel抄了个半成品是dpdk,linux不会表现的比windows更好。
--
FROM 223.66.22.*
是的,我也发现了。IBM的AIX也有IOCP系统。我说的这个东西也可以支持IOCP。
在yield的参数里增加两个:buffer,bytes 。
【 在 ensonmj 的大作中提到: 】
: linux是因为免费吧。在异步方面windows的iocp比epoll还是nb一点的,io_uring 的生态还差得远
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
你报几个头部公司名字,我去看看有没有
熟人了解的
【 在 ziqin 的大作中提到: 】
: 因为你在说纳秒级别 如果kernel by pass只省了纳秒级别 那么用cpu跑交易逻辑是没有意义的 因为随便一个大一些的cache miss或者cpu 切片都比这个大
:
: 所有你看见的纳秒级的tick to trade的 都是交易逻辑直接烧在网卡芯片里的
: ...................
--
FROM 172.56.160.*
Windows 和 C# 都是好东东。本青经常吹爆 win32api,可惜都是巨硬家的。那就没办法了。业界也是一样,不爱用巨硬家的。被坑怕了。
【 在 leadu 的大作中提到: 】
: 不参与你们对协程的讨论,太蠢了
: 如果一个系统可以上通用os,windows有rio,intel抄了个半成品是dpdk,linux不会表现的比windows更好。
: 除非你裁剪linux内核,但都到了要裁剪内核的地步,我为啥不写点verilog直接fpga甚至asic搞定?
: ...................
--
修改:hgoldfish FROM 120.33.8.*
FROM 120.33.8.*
协程调度可以由epoll进行,基于如下特性:
1.事件fd直接绑定context,事件响应直接提供context。减少了一个根据fd查找context的过程。
2.任何线程可以在任何时候把fd和context投入epoll,并且立即生效,不需要另外的激活操作。这条决定了任何线程在任何时候对任何context执行“挂起”。
3.任何线程都可以进行epoll_wait,它守候的是所有的事件,而不仅是自己投入的那个。这就决定了,当线程把context投入epoll后,就可以为所有的事件fd服务,为任何context执行resume。实现了线程和协程之间的任务切换。
BSD的Kqueue也具有这些功能,也可以作为协程调度器。这种设计恰恰不是自己造轮子,完全就是使用系统轮子。
使用过libaio,异步文件读写,任务提交后,线程还要等待任务完成。撒不开手,期间不能切换任务。解决方法是,配个eventfd,连同context,丢进epoll,让它协助调度协程。
select,也凑合可以调度协程。
任何线程都可以设置efds,但是要激活一下守候线程。只有唯一一个线程可以守候select。
事件激活后,要查找是哪一个context。然后把context丢进一个队列,队列的另一端是很多个线程在守候,之后的过程就与epoll一样了。
现在我担心的是,IOCP,是否具备协程调度功能。
【 在 hgoldfish 的大作中提到: 】
: 没这么简单哦。。你可以参考一下 libgo 和 cppcoro 啊。看看它们是怎么实现协程版本的 mutex, timer 等等的。
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
libaio没有协程调度功能,下述代码看到eventfd,协助任务调度,把efd放进yield,并投入epoll。当异步IO完成时,激活epoll,resume。
static int AIO_oper(int fd,char *buff,size_t iosize,int flg)
{
io_context_t myctx;
int rc,num;
uint64_t finished_aio;
struct iocb _iocb,*io=&_iocb;
struct io_event event;
int efd = eventfd(0, 0);
T_YIELD yield=get_yield();
if (efd == -1) {
return flg?write(fd,buff,iosize):read(fd,buff,iosize);
}
memset(&myctx,0,sizeof(myctx));
io_set_eventfd(io,efd);//绑定efd
io_queue_init(1, &myctx);
if(flg) io_prep_pread(io, fd, buff, iosize, 0);
else io_prep_pwrite(io, fd, buff, iosize, 0);
rc = io_submit(myctx, 1, &io);
if(rc<0) {
close(efd);
io_destroy(myctx);
return flg?write(fd,buff,iosize):read(fd,buff,iosize);
}
if(yield) {
rc = yield(efd,0,0);//把eventfd丢给epoll
if(rc==0) eventfd_read(efd, &finished_aio);
}
如果不是协程(没有yield),后边自己等待完成。
【 在 ylh0315 的大作中提到: 】
: 协程调度可以由epoll进行,基于如下特性:
: 1.事件fd直接绑定context,事件响应直接提供context。减少了一个根据fd查找context的过程。
: 2.任何线程可以在任何时候把fd和context投入epoll,并且立即生效,不需要另外的激活操作。
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
每个线程只有一个timerfd,每个timerfd几百毫秒产生一次EPOLLOUT,代价不会很大吧
而让epoll带一个小的超时时间提早返回,也一样得从内核态往用户态转,然后还是一样得重新回到epoll wait,
让epoll带一个小的超时时间提早返回和用timerfd,好像是个朝三暮四的问题吧
【 在 hgoldfish 的大作中提到: 】
: timerfd 要陷入内核态的。这个方案也太差了吧。一般是 epoll() 那边带一个超时参数搞定。不过新的 uring 好像没超时参数了。
:
--
FROM 113.120.108.*
如果连接(协程)数量很多的话,每个都配一个deadline timer或者steady_timer,代价似乎很大吧
其实批量对齐处理足够了,比如100ms或者50ms一次批量对齐处理超时,这样的代价可能是有点协程超时处理稍稍晚了一点点,但对于绝大部分(除了超高实时性要求的)系统来说,精确度已经足够了
何况deadline timer本来也不保证能非常精确的返回,有时候会早一点有时候会晚一点
【 在 ziqin 的大作中提到: 】
: 每个协程配一个asio deadline timer 不过看他对他那个构架这么津津乐道的样子 估计没用过asio框架
:
: 他这点需求和吞吐量 对asio根本不是个事
: ...................
--
FROM 113.120.108.*
是的,就是由主线程批量处理,为了减小开销,15秒检测一次,精度比较低,但是对于交易来说,够用。这个数可以改。见88楼。
另外,timerfd的方案,一个麻烦是,每个操作正常进行都要想着消掉定时器,这个太麻烦了。
目前的方案是,业务流程只需要设置时间戳和超时值,别的就不用管了。
【 在 wallyz 的大作中提到: 】
: 如果连接(协程)数量很多的话,每个都配一个deadline timer或者steady_timer,代价似乎很大吧
: 其实批量对齐处理足够了,比如100ms或者50ms一次批量对齐处理超时,这样的代价可能是有点协程超时处理稍稍晚了一点点,但对于绝大部分(除了超高实时性要求的)系统来说,精确度已经足够了
: 何况deadline timer本来也不保证能非常精确的返回,有时候会早一点有时候会晚一点
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*