该select()和pselect()系统调用修改其参数（在“
fd_set *”参数），所以输入值告诉系统文件描述符检查和返回值告诉程序员哪些文件描述符当前可用它。

如果要为同一组文件描述符重复调用它们，则需要确保每个调用都有一个描述符的新副本。显而易见的方法是使用结构副本：

fd_set ref_set_rd;
fd_set ref_set_wr;
fd_set ref_set_er;
...
...code to set the reference fd_set_xx values...
...
while (!done)
{
    fd_set act_set_rd = ref_set_rd;
    fd_set act_set_wr = ref_set_wr;
    fd_set act_set_er = ref_set_er;
    int bits_set = select(max_fd, &act_set_rd, &act_set_wr,
                          &act_set_er, &timeout);
    if (bits_set > 0)
    {
        ...process the output values of act_set_xx...
    }
 }

（已 编辑以删除不正确的struct fd_set引用-如“ R ..”所指出。）

我的问题：

• 是否存在不安全地复制fd_set所示值的结构的平台？

我担心，以免存在隐藏的内存分配或类似的意外情况。（有宏/功能FD_SET（），FD_CLR（），FD_ZERO（）和FD_ISSET（）可以掩盖应用程序的内部结构。）

我可以看到MacOS X（Darwin）是安全的；因此，其他基于BSD的系统可能是安全的。您可以通过记录已知在答案中安全的其他系统来提供帮助。

（我确实不太关心它fd_set与8192个以上打开文件描述符的配合情况-默认打开文件的最大数量仅为256个，但最大数量为“无限制”。而且，由于结构为1
KB，因此复制代码的效率并不高，但是在每个循环中遍历文件描述符列表来重新创建输入掩码也不一定有效，也许select()当打开了这么多文件描述符时您就无法执行，尽管那是当您最有可能需要此功能。）

有一个相关的SO问题-询问[“ poll（）vsselect（）”]，它解决了与此问题不同的一系列问题。

请注意，在MacOS X（大概是BSD）上，有一个FD_COPY()带有有效原型的宏或函数：

• extern void FD_COPY(const restrict fd_set *from, restrict fd_set *to);。

在尚不可用的平台上，可能值得进行仿真。