谈谈误解------为什么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的感觉， 对了， 就是它。

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