很多书本和网上都说: 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的感觉, 对了, 就是它。
好了, 不多扯, 干正事去。