select多路复用的简单问题，但是非常困惑

[maptrix]

在使用select来监听套接字是否有数据接收等等事件发生的时候，正常情况下返回就绪的文件描述符个数。并且在readfds、writefds和exceptfds中保留那些就绪的套接字描述符。如果是这样在大部分的多路复用的时候是不是可以如下使用

...
nRes = select(nSockMax + 1, &ReadFDs, 0, 0, &TimeOut);
...
for(int i = 0; i < ReadFDs.fd_count; i++)
{
ReadFDs.fd_array[i];//直接使用套接字读取数据
}

不知道这种用法是否合理，我在windows下使用发现这样做可行，但是不知道有没有别的问题？linux平台下没有测试过。

通常使用的方法是
for(int i = 0; i < nAllFdsCount; i++)
{
if (FD_ISSET(AllFds[i], &ReadFDs)
{
AllFds[i];//直接使用套接字
}
}

当被监听的套接字组的数量很大的时候，这样的循环是否会浪费CPU效率，但是几乎所有的例子里面都是这样写的。请高手指点一下第一种方法的问题在哪儿？

[zjzf_1]

while(1){
accpept当有连接进来的时候返回新的socket
这时候 你fork一个新的进程 处理这个连接
}
如果是进程的话 我通常都用这个办法
如果为了快 可以考虑 预先派生 子进程 等办法

[baoyuhua]

linux下的伯克利套接字中fd_set结构同windows平台下的FD_SET结构不同，所以这样做不具备可移植性。

[baoyuhua]

这种循环检测是必然的，但耗费的cpu资源是很低的，所以这一点不用担心。
select函数本身需要对小于maxfd的每个套接字进行检测（可能这其中只有
几个套接字使用FD_SET注册，也即是应用程序感兴趣的套接字仅有几个），
但select仍然要对小于maxfd的每一个套接字进行检测，所以从效率上考虑
就有改进的必要，这种情况下通常采用poll作为替代，因为poll采用了套接
字数组来通知内核应用程序对那些套接字感兴趣，所以内核就不必检测所有
已打开的文件描述符，从效率上来说这是优于select的。

[baoyuhua]

但是poll的可移植性略低于select，因为poll仅在兼容于SYSV的系统中提供

[ZhangYv]

http://blog.csdn.net/zhangyv/archive/2005/02/17/291051.aspx

[maptrix]

其实我就想知道第一种方法里面的，那种直接使用的方法有什么不妥的地方。

实在不行，实在在以后的实际应用中慢慢的摸索，到底是否实用，而且在linux的平台上运行有些什么问题。