谈谈误解------为什么select支持的fd数量有限制,而poll/epoll等支持的fd数量没有限制?

        很多书本和网上都说: poll/epoll比select好的地方之一在于:select支持的最大fd数量有限制,而poll/epoll等支持的最大fd数量没有限制。 这句话本身没有太多问题, 但我纳闷, 一般来说,  单个进程(在一个典型的linux机器上,  比如我的机器就是这样)能打开的最大fd数据为1024, 你说select能最多能支持1024个fd, 我理解。 但你说poll/epoll就那么牛逼, 能让单进程打开的fd数目突破1024, 我看这是扯淡, 完全是误解。

        这里要区分两个概念: 

        1. 单进程能打开的最大fd数目, 通常是1024(也可能是2048), 当然, 这个值也是可以更改的。 在本文的讨论中, 为了方便, 我们假设是1024.

        2. poll/epoll支持的最大fd数目, 这个数目是没有限制的(可以认为理论上没限制, 比如可以达到1万或者10万).


        这下明白了, 也就是说, 大致来讲, 不管你系统单进程能打开的最大fd数是不是1024, 反正select就支持这么多。  不管你系统单进程能打开的最大fd数是不是1024, 反正poll/epoll支持的数量没有限制。

        所以, 并不是说, 你用了poll/epoll后, 你的系统变牛逼了, 并不是说, 你用了poll/epoll后, 你的系统的单进程打开的最大fd数能变得没有限制。


        最后, 附上一点linux源码, 让我们来看看为什么select时有限制:

static __inline__ void __FD_SET(unsigned long fd, __kernel_fd_set *fdsetp)
{
    unsigned long _tmp = fd / __NFDBITS;
    unsigned long _rem = fd % __NFDBITS;
    fdsetp->fds_bits[_tmp] |= (1UL<<_rem);
}

#define __NFDBITS    (8 * sizeof(unsigned long))

typedef struct {
    unsigned long fds_bits [__FDSET_LONGS];
} __kernel_fd_set;

#define __FDSET_LONGS   (__FD_SETSIZE/__NFDBITS)

#define __FD_SETSIZE    1024

         对了, 看看上面的linux源码, 是不是有点bitmap的感觉, 对了, 就是它。


         好了, 不多扯, 干正事去。  

       

涛歌依旧 CSDN认证博客专家 CSDN排名第一 点链接学人工智能 公众号免费领资料
❤️零基础入门进阶人工智能
❤️欢迎关注涛哥公众号,免费领海量学习资料。涛哥:毕业后就职于华为和腾讯。微信:ai_taogeyijiu
已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 技术工厂 设计师:CSDN官方博客 返回首页