设计极其糟糕的select函数
设计极其糟糕的select函数
相较Windows而言,大部分UNIX API函数设计都比较考究,但也有少数简直就是奇葩,select函数正是这些奇葩中非常灿烂的一朵。我原来一致钟情于ACE,接触的只是reactor,最近由于开始自己设计网络层的类库,被迫和select打了一些交道,被迫和这个函数打了一些交道,结果只能是看着就吐了,吐着吐着就习惯了。
UNIX下select这个API由主函数select和几个fd_set辅助函数构成。如下:
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); void FD_CLR(int fd, fd_set *set); int FD_ISSET(int fd, fd_set *set); void FD_SET(int fd, fd_set *set); void FD_ZERO(fd_set *set); //fd_set的实际结构是__kernel_fd_set typedef struct { unsigned long fds_bits [__FDSET_LONGS]; } __kernel_fd_set;
select主函数的第一个参数nfds的描述是 nfds is the highest-numbered file descriptor in any of the three sets, plus 1.也就是最大的文件句柄数值+1,这个参数的本质意图应该是加快内部处理的,避免内部处理几个fd_set的时候都不用处理次数,从而降低系统的计算销毁,但是select本来就是要处理3个fd_set,这个nfds就只能是这3个fd_set中间的最大值,而且考虑到nfds不可能一直增加,而不减少,在FD_CLR清理掉某个句柄后,找一个新的最大值,必须和3个fd_set打交道。简直是……,很多人,很多库的处理FD_CLR后,其实会偷懒不减少nfds。这个其实不是大家的错,而是select设计者的原罪。(当然你也可以像ACE那样包装一层加快实现)
改良的方案很简单,考虑到fd_set本来就只是内部的一个结构,每个结构拥有自己的最大值,是一件非常easy的事情。这样就可以取消那个讨厌的nfds参数。我们后面看Windows下的select设计时会继续讨论这个问题。
由于3个fd_set参数都是传入传出参数,所以如果是服务器程序,你老只好在每次调用select前保留一次这些句柄。
再来看看这个UNIX大部分设计中fd_set的实现,他就是一个用bit位标识文件句柄的long数组。所以他只能处理文件句柄数值小于1024的文件句柄,由于还有其他地方会占用前面的文件句柄ID,所以其实UNIX的select根本无法处理FD_SETSIZE个网络请求。甚至极端情况下你的程序一开始就打开了1024个文件,你就别想使用这个可爱的函数,他就没有这个处理能力……
Windows下的select函数基本向UNIX平台靠齐,但是由于Windows下HANDLE(SOCKET)完全不是整数(而是一个指针),Windows的select,可以实际处理FD_SETSIZE个文件句柄(Windows下这个参数默认64,可以在保护winsock2.h前面重新定义这个宏调整)。Windows下的select函数就没有使用第一个参数,其通过设计fd_set达到了同样加速的目的。
//Windows下的fd_set的定义 typedef struct fd_set { //如果UNIX的fd_set也有这个参数,那么UNIXselect函数的处理也简单了 u_int fd_count; /* how many are SET? */ SOCKET fd_array[FD_SETSIZE]; /* an array of SOCKETs */ } fd_set;
最后我们看看FD_ISSET的设计,大部分select的例子都是使用FD_ISSET判断某个句柄是否被触发的,但是真正我们写服务器时,如果要老老实实使用FD_ISSET,方法就只能是自己先保存一组放入select的句柄参数。然后将这些句柄取出一个个和返回的fd_set用FD_ISSET进行判断,所以这个成本至少是一个O(nfds),而在Windows下,由于句柄ID不可能直接映射查找。查询效率应该是O(输入参数fd_set的数量*触发返回的fd_set的数量)。Windows下有没有快一点的法子呢,有,就是不用FD_ISSET,直接利用fd_set的结构。处理效率就只需要O(触发返回的fd_set的数量),当然这又违背了select函数FD_ISEET这类函数(宏)的设计初衷,不希望你了解fd_set的内部结构。
整体说来,UNIX下的select函数的设计是完全是结合UNIX文件句柄的设计进行的,同时考虑了部分加快速度部分的处理,虽然在那个年代,也许有他的苦衷。但无需遮掩,其整体设计是比较失败的,既没有效率,也没有考虑扩展性,而Windows下select的设计比UNIX版本高出一节。而如果把epoll的API拿出来比一下,高下立分。
【本文作者是fullsail(雁渡寒潭),本着自由的精神,你可以在无盈利的情况完整转载此文档,转载时请附上BLOG链接:http://www.cnblogs.com/fullsail,否则每字一元不讲价。对Baidu文库加价一倍】