fd_set与select(转)
fd_set是文件句柄的集合。
FD_ZERO&&&
清空这个集合；
FD_SET　往这个集合里面加入一个文件句柄；
FD_ISSET&&&&&
查看某一个文件句柄是否被设置了；
其中，select的第二个参数是“可读”文件句柄的集合；
第三个参数是“可写”文件句柄的集合；经常使用的就是这两个参数。
你可以看一下select函数的说明，里面有的。
是一组文件描述符(fd)的集合。由于fd_set类型的长度在不同平台上不同，因此应该用一组标准的宏定义来处理此类变量：
&&&& fd_&&&& FD_ZERO(&set);&&&&&&& &&&& FD_SET(fd, &set);&&&& &&&& FD_CLR(fd, &set);&&&& &&&& FD_ISSET(fd, &set);&&
在过去，一个fd_set通常只能包含少于等于32个文件描述符，因为fd_set其实只用了一个int的比特矢量来实现，在大多数情况下，检查
fd_set能包括任意值的文件描述符是系统的责任，但确定你的fd_set到底能放多少有时你应该检查/修改宏FD_SETSIZE的值。*这个值是系统相关的*，同时检查你的系统中的select()
的man手册。有一些系统对多于1024个文件描述符的支持有问题。
#ifndef FD_SETSIZE
FD_SETSIZE&&&&&&
typedef struct fd_set
WinSock 编程中有一很方便的地方便是其消息驱动机制，不管是底层 API 的 WSAAsyncSelect() 还是 MFC
的异步Socket类：
CAsyncSocket，都提供了诸如 FD_ACCEPT、FD_READ、FD_CLOSE
之类的消息& 编程人员捕捉并处理。FD_ACCEPT
通知进程有客户方Socket请求连接，& D_READ通知进程本地Socket有东西可读。SD
UNIX中有一系统调用芳名select()完全可以提供类似的消息驱动机制。
WinSock的WSAAsyncSeclet()不过是此select()的fork版！
select()的机制中提供一fd_set的数据结构，实际上是一long类型的数组，一个数组元素都能与一打开的文件句柄（不管是Socket句柄,还是其他
文件或命名管道或设备句柄）建立联系，建立联系的工作由程序员完成（利用FD_SET宏），当调用select()时，由内核根据IO状态修改fd_set的内容，由此来通知执行了select()的进程哪一Socket或文件可读，下面具体解释：
&sys/types.h&
&sys/times.h&
&sys/select.h&
int select(nfds, readfds, writefds, exceptfds, timeout)
fd_set *readfds, *writefds, *
struct timeval *
ndfs：select监视的文件句柄数，视进程中打开的文件数而定,一般设为要监视各文件中的最大文件号加一。
readfds：select监视的可读文件句柄集合。
writefds: select监视的可写文件句柄集合。
exceptfds：select监视的异常文件句柄集合。
timeout：本次select()的超时结束时间。
当readfds或writefds中映象的文件可读或可写或超时，本次select()
结束返回。程序员利用一组系统提供的宏在select()结束时便可判断哪一文件可读或可写。对Socket编程特别有用的就是readfds。只相关的宏解释如下：
FD_ZERO(fd_set *fdset)：清空fdset与所有文件句柄的联系。
FD_SET(int fd, fd_set *fdset)：建立文件句柄fd与fdset的联系。
FD_CLR(int fd, fd_set *fdset)：清除文件句柄fd与fdset的联系。
FD_ISSET(int fd, fdset *fdset)：检查fdset联系的文件句柄fd是否
可读写，&0表示可读写。
（关于fd_set及相关宏的定义见/usr/include/sys/types.h）
这样，你的socket只需在有东东读的时候才读入，大致如下：
fd_set& fdR;
struct& timeval timeout = ..;
FD_ZERO(&fdR);
FD_SET(sockfd, &fdR);
switch (select(sockfd + 1, &fdR, NULL,
&timeout)) {
if (FD_ISSET(sockfd)) {
所以一个FD_ISSET(sockfd)就相当通知了sockfd可读。 至于struct timeval在此的功能，请man
select。不同的timeval设置使select()表现出超时结束、无超时阻塞和轮询三种特性。由于
imeval可精确至百万分之一秒，所以Windows的SetTimer()根本不算什么。你可以用select()做一个超级时钟。
FD_ACCEPT的实现？依然如上，因为客户方socket请求连接时，会发送
连接请求报文，此时select()当然会结束，FD_ISSET(sockfd)当然大
于零，因为有报文可读嘛！至于这方面的应用，主要在于服务方的父
Socket，你若不喜欢主动accept()，可改为如上机制来accept()。
至于FD_CLOSE的实现及处理，颇费了一堆cpu处理时间，未完待续。
讨论关于利用select()检测对方Socket关闭的问题：
仍然是本地Socket有东东可读，因为对方Socket关闭时，会发一个关闭连接
通知报文，会马上被select()检测到的。关于TCP的连接（三次握手）和关
闭（二次握手）机制，敬请参考有关TCP/IP的书籍。
不知是什么原因，UNIX好象没有提供通知进程关于Socket或Pipe对方关闭的
信号，也可能是cpu所知有限。总之，当对方关闭，一执行recv()或read()，
马上回返回-1，此时全局变量errno的值是115，相应的sys_errlist[errno]
为"Connect refused"（请参考/usr/include/sys/errno.h）。所以，在上
篇的for(;;) ...select()程序块中，当有东西可读时，一定要检查recv()或
read()的返回值，返回-1时要作出关断本地Socket的处理，否则select()会
一直认为有东西读，其结果曾几令cpu伤心欲断针脚。不信你可以试试：不检
查recv()返回结果，且将收到的东东（实际没收到）写至标准输出...
在有名管道的编程中也有类似问题出现。具体处理详见拙作：发布一个有用
的Socket客户方原码。
至于主动写Socket时对方突然关闭的处理则可以简单地捕捉信号SIGPIPE并作
出相应关断本地Socket等等的处理。SIGPIPE的解释是：写入无读者方的管道。
在此不作赘述，请详man signal。
以上是cpu在作tcp/ip数据传输实验积累的经验，若有错漏，请狂炮击之。
唉，昨天在hacker区被一帮孙子轰得差点儿没短路。ren cpu(奔腾的心) z80
补充关于select在异步(非阻塞)connect中的应用,刚开始搞socket编程的时候
我一直都用阻塞式的connect,非阻塞connect的问题是由于当时搞proxy scan
而提出的呵呵
通过在网上与网友们的交流及查找相关FAQ,总算知道了怎么解决这一问题.同样
用select可以很好地解决这一问题.大致过程是这样的:
1.将打开的socket设为非阻塞的,可以用fcntl(socket, F_SETFL, O_NDELAY)完
成(有的系统用FNEDLAY也可).
2.发connect调用,这时返回-1,但是errno被设为EINPROGRESS,意即connect仍旧
在进行还没有完成.
3.将打开的socket设进被监视的可写(注意不是可读)文件集合用select进行监视,
如果可写,用
getsockopt(socket, SOL_SOCKET, SO_ERROR, &error,
sizeof(int));
来得到error的值,如果为零,则connect成功.
在许多unix版本的proxyscan程序你都可以看到类似的过程,另外在solaris精华
区-&编程技巧中有一个通用的带超时参数的connect模块.
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。精确延时(usleep,nanosleep,select)
再论精确延时(usleep,nanosleep,select)
#include &stdio.h&;
#include &stdlib.h&;
#include &time.h&;
#include &sys/time.h&;
#include &errno.h&;
#include &string.h&;
#include &unistd.h&;
#include &sys/types.h&;
#define PRINT_USEAGE& { \
&& fprintf(stderr,"\n Usage: %s
usec ",argv[0]); \
&& fprintf(stderr,"\n\n");\
main (int argc, char **argv)
& unsigned int nTimeTestSec =
& unsigned int nTimeTest =
& struct timeval tvB
& struct timeval tvN
& int ret = 0;
& unsigned int nDelay =
& int fd = 1;
& int i = 0;
& unsigned int delay[20] =
&&& { 500000,
000, 1, 900, 500, 100, 10, 1, 0 };
& int nReduce =
0;&&&&&&&&&&&&&&&
& if (argc & 2)
PRINT_USEAGE;
& nDelay = atoi (argv[1]);
& fprintf (stderr, "ssss\n", "function",
"time(usec)", "realTime",
&&&&&&&&&&
"reduce");
& fprintf (stderr,
&&&&&&&&&&
"-------------------------------------------------------------------\n");
& for (i = 0; i & 20; i++)
if (delay[i] &= 0)
nDelay = delay[i];
gettimeofday (&tvBegin, NULL);
ret = usleep (nDelay);
if (-1 == ret)
fprintf (stderr, " usleep error . errno=%d [%s]\n", errno,
&&&&&&&&&&&&&&&&&&
strerror (errno));
gettimeofday (&tvNow, NULL);
nTimeTest =
(tvNow.tv_sec - tvBegin.tv_sec) * 1000000 + tvNow.tv_usec -
tvBegin.tv_
nReduce = nTimeTest - nD
fprintf (stderr, "\t
usleep&&&&&&
%8u&& �\n", nDelay,
nTimeTest,nReduce);
gettimeofday (&tvBegin, NULL);
req.tv_sec = nDelay / 1000000;
req.tv_nsec = (nDelay % 1000000) * 1000;
ret = nanosleep (&req, NULL);
if (-1 == ret)
fprintf (stderr, "\t
nanosleep&&&
%8u&& not support\n",
gettimeofday (&tvNow, NULL);
nTimeTest =
&&&&&&&&&&&
(tvNow.tv_sec - tvBegin.tv_sec) * 1000000 + tvNow.tv_usec -
&&&&&&&&&&&
tvBegin.tv_
nReduce = nTimeTest - nD
fprintf (stderr, "\t
nanosleep&&&
%8u&& �\n", nDelay,
&&&&&&&&&&&&&&&&&&
nTimeTest, nReduce);
gettimeofday (&tvBegin, NULL);
FD_ZERO (&rfds);
FD_SET (fd, &rfds);
tv.tv_sec = 0;
tv.tv_usec = nD
ret = select (0, NULL, NULL, NULL, &tv);
if (-1 == ret)
fprintf (stderr, " select error . errno=%d [%s]\n", errno,
&&&&&&&&&&&&&&&&&&
strerror (errno));
gettimeofday (&tvNow, NULL);
nTimeTest =
(tvNow.tv_sec - tvBegin.tv_sec) * 1000000 + tvNow.tv_usec -
tvBegin.tv_
nReduce = nTimeTest - nD
fprintf (stderr, "\t
select&&&&&&
%8u&& �\n", nDelay,
nTimeTest,
&&&&&&&&&&&&&&
& return 0;
---------------------------------------------------------------------------------------------------------------------------------------------------
IBM AIX 3.4 单CPU
sleep& 可以在多线程中使用，只阻塞本线程，不影响所属进程中的其它线程
不支持 nanosleep
支持 usleep& 和 select
以下采用 gettimeofday 对 usleep 和 select 的实际精确情况进行测试分析
time(usec)&&&
realTime&&&&&
-------------------------------------------------------------------
usleep&&&&&&&&
500000&&&&
500026&&&&&&&&
nanosleep&&&&&
500000&& not support
select&&&&&&&&
500000&&&&
500026&&&&&&&&
usleep&&&&&&&&
100000&&&&
100021&&&&&&&&
nanosleep&&&&&
100000&& not support
select&&&&&&&&
100000&&&&
100025&&&&&&&&
usleep&&&&&&&&&
50000&&&&&
50021&&&&&&&&
nanosleep&&&&&&
50000&& not support
select&&&&&&&&&
50000&&&&&
50107&&&&&&&
usleep&&&&&&&&&
10000&&&&&
10099&&&&&&&&
nanosleep&&&&&&
10000&& not support
select&&&&&&&&&
10000&&&&&
10025&&&&&&&&
usleep&&&&&&&&&&
1000&&&&&&
1021&&&&&&&&
nanosleep&&&&&&&
1000&& not support
select&&&&&&&&&&
1000&&&&&&
1024&&&&&&&&
usleep&&&&&&&&&&&
900&&&&&&&
920&&&&&&&&
nanosleep&&&&&&&&
900&& not support
select&&&&&&&&&&&
1024&&&&&&&
usleep&&&&&&&&&&&
500&&&&&&&
523&&&&&&&&
nanosleep&&&&&&&&
500&& not support
select&&&&&&&&&&&
1024&&&&&&&
usleep&&&&&&&&&&&
100&&&&&&&
119&&&&&&&&
nanosleep&&&&&&&&
100&& not support
select&&&&&&&&&&&
1023&&&&&&&
usleep&&&&&&&&&&&&
10&&&&&&&&
31&&&&&&&&
nanosleep&&&&&&&&&
10&& not support
select&&&&&&&&&&&&
1024&&&&&&
usleep&&&&&&&&&&&&&
19&&&&&&&&
nanosleep&&&&&&&&&&
1&& not support
select&&&&&&&&&&&&&
1026&&&&&&
由此可以得出，在AIX 3.4下：
&&&&&&&&&&&&&&&
select 只能精确到毫秒级别
&&&&&&&&&&&&&&&
usleep 可以精确到微秒级
&&&&&&&&&&&&&&&
在1毫秒以上，两者的精确度基本一样
同上，在 linux 2.4.20-8smp 双CPU 下测试
time(usec)&&&
realTime&&&&&
-------------------------------------------------------------------
usleep&&&&&&&&
500000&&&&
506453&&&&&&
nanosleep&&&&&
500000&&&&
509930&&&&&&
select&&&&&&&&
500000&&&&
499990&&&&&&&
usleep&&&&&&&&
100000&&&&
110023&&&&&
nanosleep&&&&&
100000&&&&
109955&&&&&&
select&&&&&&&&
100000&&&&&
99992&&&&&&&&
usleep&&&&&&&&&
50000&&&&&
59971&&&&&&
nanosleep&&&&&&
50000&&&&&
59990&&&&&&
select&&&&&&&&&
50000&&&&&
50025&&&&&&&&
usleep&&&&&&&&&
10000&&&&&
19991&&&&&&
nanosleep&&&&&&
10000&&&&&
19988&&&&&&
select&&&&&&&&&
10000&&&&&&
9956&&&&&&&
usleep&&&&&&&&&&
19990&&&&&
nanosleep&&&&&&&
19989&&&&&
select&&&&&&&&&&
10024&&&&&&
usleep&&&&&&&&&&&
20009&&&&&
nanosleep&&&&&&&&
19972&&&&&
select&&&&&&&&&&&
9943&&&&&&
usleep&&&&&&&&&&&
19975&&&&&
nanosleep&&&&&&&&
19971&&&&&
select&&&&&&&&&&&
10012&&&&&&
usleep&&&&&&&&&&&
19975&&&&&
nanosleep&&&&&&&&
19976&&&&&
select&&&&&&&&&&&
9943&&&&&&
usleep&&&&&&&&&&&&
19988&&&&&
nanosleep&&&&&&&&&
19961&&&&&
select&&&&&&&&&&&&
10011&&&&&
usleep&&&&&&&&&&&&&
19978&&&&&
nanosleep&&&&&&&&&&
19985&&&&&
select&&&&&&&&&&&&&
9932&&&&&&
在 2.4.21-4.ELsmp #1 SMP& 4 CPU 下测试
&&&&&&&&&&
time(usec)&&&
realTime&&&&&
-------------------------------------------------------------------
usleep&&&&&&&&
500000&&&&
501267&&&&&&
nanosleep&&&&&
500000&&&&
509964&&&&&&
select&&&&&&&&
500000&&&&
499981&&&&&&&
usleep&&&&&&&&
100000&&&&
109944&&&&&&
nanosleep&&&&&
100000&&&&
109925&&&&&&
select&&&&&&&&
100000&&&&&
99963&&&&&&&
usleep&&&&&&&&&
50000&&&&&
59904&&&&&&
nanosleep&&&&&&
50000&&&&&
59973&&&&&&
select&&&&&&&&&
50000&&&&&
49956&&&&&&&
usleep&&&&&&&&&
10000&&&&&
19988&&&&&&
nanosleep&&&&&&
10000&&&&&
20008&&&&&
select&&&&&&&&&
10000&&&&&
10020&&&&&&&&
usleep&&&&&&&&&&
19988&&&&&
nanosleep&&&&&&&
19980&&&&&
select&&&&&&&&&&
1000&&&&&&
9943&&&&&&
usleep&&&&&&&&&&&
19975&&&&&
nanosleep&&&&&&&&
19986&&&&&
select&&&&&&&&&&&
9905&&&&&&
usleep&&&&&&&&&&&
19989&&&&&
nanosleep&&&&&&&&
19910&&&&&
select&&&&&&&&&&&
10000&&&&&&
usleep&&&&&&&&&&&
19355&&&&&
nanosleep&&&&&&&&
19902&&&&&
select&&&&&&&&&&&
9988&&&&&&
usleep&&&&&&&&&&&&
19977&&&&&
nanosleep&&&&&&&&&
19988&&&&&
select&&&&&&&&&&&&
9943&&&&&&
usleep&&&&&&&&&&&&&
20007&&&&&
nanosleep&&&&&&&&&&
19947&&&&&
select&&&&&&&&&&&&&
9980&&&&&&
&&&&&&&&&&&&&&&
由此可以得出如下结论，在 linux 2.4 下：
&&&&&&&&&&&&&&&&&&&&&&&
1、支持 usleep,nanosleep,select
&&&&&&&&&&&&&&&&&&&&&&&
2、select 的 精确度为 10毫秒。在10毫秒以上很精确
&&&&&&&&&&&&&&&&&&&&&&&
3、usleep， nanosleep& 很不精确
&&&&&&&&&&&&&&&
同样，通过其它测试程序能得出如下结论：
&&&&&&&&&&&&&&&&&&&&&&&
sleep& 可以在多线程中使用，只阻塞本线程，不影响所属进程中的其它线程
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhoujunyi/archive//1546330.aspx
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}