ACE_TAO 016 USE_SELECT和ACE_USE_POLL

Posted 2022-11-27 islinyoubiao

看一段代码，在Event_Handler.h中

#if defined (ACE_USE_POLL)
    READ_MASK = POLLIN,
    WRITE_MASK = POLLOUT,
    EXCEPT_MASK = POLLPRI,
#else /* USE SELECT */
    READ_MASK = (1 << 0),
    WRITE_MASK = (1 << 1),
    EXCEPT_MASK = (1 << 2),

select，poll，epoll都是IO多路复用的机制。IO多路利用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步IO，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步IO则无需自己负责进行读写，异步IO的实现会负责把数据从内核拷贝到用户空间。

在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。（此时去掉了遍历文件描述符，而是通过监听回调的机制。这正是epoll的魅力所在。）

先说Select：

1。Socket数量限制：该模式可操作的Socket数由FD_SETSIZE决定，内核默认32*32=1024。

2。操作限制：通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历一遍。

后说Poll：

1。Socket数量几乎无限制：该模式下的Socket对应的fd列表由一个数组来保存，大小不限（默认4k）。

2。操作限制：同Select。

再说：Epoll：

1。Socket数量无限制：同Poll。

2。操作无限制：基于内核提供的反射模式，有活跃Socket时，内核访问该Socket的callback，不需要遍历轮询。

总体来说：

大部分情况下，反射的效率都比遍历来的高，但是

但是当所有Socket都活跃的时候，反射还会更高么？这时候所有的callback都被唤醒，会导致资源的竞争，既然都是要处理所有的Socket，那么遍历是最简单最有效的实现方式。

举例来说：

对于IM服务器，服务器和服务器之间都是长链接，但数量不多，一般一台60\\70个，比如采用ICE这种架构设计，但请求相当频繁和密集，这时候反射唤醒callback不一定比用select去遍历处理更好。

对于web portal服务器，都是浏览器客户端发起的http短链接请求，数量很大，好一点的网站动辄每分钟上千个请求过来，同时服务器端还胡更多的闲置等待超时的Socket，这时候没有必要把全部的Socket都遍历处理，因为那些等待超时的请求是大多数的，这样用Epoll会更好。

http://blog.csdn.net/klarclm/article/details/8828486

https://blog.csdn.net/lileiyang12/article/details/22555727

总结：

在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自己特点。

1。表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多的函数回调。

2。select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可以通过良好的设计改善。

多谢，亲爱的美美。