Linux系统下fd分配的方法是什么

这篇文章将为大家详细讲解有关linux系统下fd分配的方法是什么，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

最近几天在公司里写网络通讯的代码比较多，自然就会涉及到io事件监测方法的问题。我惊奇的发现select轮训的方法在那里居然还大行其道。我告诉他们现在无论在Linux系统下，还是windows系统下，select都应该被废弃不用了，其原因是在两个平台上select的系统调用都有一个可以说是致命的坑。

在windows上面单个fd_set中容纳的Socket handle个数不能超过FD_SETSIZE(在win32 winsock2.h里其定义为64，以VS2010版本为准)，并且fd_set结构使用一个数组来容纳这些socket handle的，每次FD_SET宏都是向这个数组中放入一个socket handle，并且此过程中是限定了不能超过FD_SETSIZE，具体请自己查看winsock2.h中FD_SET宏的定义。

此处的问题是

若本身fd_set中的socket handle已经达到FD_SETSIZE个，那么后续的FD_SET操作实际上是没有效果的，对应socket handle的IO事件将被遗漏！！！

而在Linux系统下面，该问题其实也是处在fd_set的结构和FD_SET宏上。此时fd_set结构是使用bit位序列来记录每一个待检测IO事件的fd。记录的方式稍微复杂，如下

/usr/include/sys/select.h中

typedef long int __fd_mask;  #define __NFDBITS    (8 * sizeof (__fd_mask))  #define    __FDELT(d)    ((d) / __NFDBITS)   #define    __FDMASK(d)    ((__fd_mask) 1 << ((d) % __NFDBITS))   typedef struct    {        #ifdef __USE_XOPEN      __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];  # define __FDS_BITS(set) ((set)->fds_bits)  #else      __fd_mask __fds_bits[__FD_SETSIZE / __NFDBITS];  # define __FDS_BITS(set) ((set)->__fds_bits)  #endif    } fd_set;   #define    FD_SET(fd, fdsetp)    __FD_SET (fd, fdsetp)

/usr/include/bits/select.h中

1 # define __FD_SET(d, set)    (__FDS_BITS (set)[__FDELT (d)] |= __FDMASK (d))

可以看出，在上面的过程，实际上每个bit在fd_set的bit序列中的位置对应于fd的值。而fd_set结构中bit位个数是__FD_SETSIZE定义的，__FD_SETSIZE在/usr/include/bits/typesize.h(包含关系如下sys/socket.h -> bits/types.h -> bits/typesizes.h)中被定义为1024。

现在的问题是，当fd>=1024时，FD_SET宏实际上会引起内存写越界。而实际上在man select中对已也有明确的说明，如下

NOTES

An fd_set is a fixed size buffer. Executing FD_CLR() or FD_SET() with a value of fd that is negative or is equal to or
larger than FD_SETSIZE will result in undefined behavior. Moreover, POSIX requires fd to be a valid file descriptor.

这一点包括之前的我，是很多人没有注意到的，并且云风大神有篇博文《一起 select 引起的崩溃》也描述了这个问题。

可以看出在Linux系统select也是不安全的，若想使用，得小心翼翼的确认fd是否达到1024，但这很难做到，不然还是老老实实的用poll或epoll吧。

扯得有点远了，但也引出了本片文章要叙述的主题，就是Linux系统下fd值是怎么分配确定，大家都知道fd是int类型，但其值是怎么增长的，在下面的内容中我对此进行了一点分析，以2.6.30版本的kernel为例，欢迎拍砖。

首先得知道是哪个函数进行fd分配，对此我以pipe为例，它是分配fd的一个典型的syscall，在fs/pipe.c中定义了pipe和pipe2的syscall实现，如下

SYSCALL_DEFINE2(pipe2, int __user *, fildes, int, flags)  {      int fd[2];      int error;       error = do_pipe_flags(fd, flags);      if (!error) {          if (copy_to_user(fildes, fd, sizeof(fd))) {              sys_close(fd[0]);              sys_close(fd[1]);              error = -EFAULT;          }      }      return error;  }   SYSCALL_DEFINE1(pipe, int __user *, fildes)  {      return sys_pipe2(fildes, 0);  }

进一步分析do_pipe_flags()实现，发现其使用get_unused_fd_flags(flags)来分配fd的，它是一个宏

#define get_unused_fd_flags(flags) alloc_fd(0, (flags))，位于include/linux/fs.h中

好了咱们找到了主角了，就是alloc_fd()，它就是内核章实际执行fd分配的函数。其位于fs/file.c，实现也很简单，如下

int alloc_fd(unsigned start, unsigned flags)  {      struct files_struct *files = current->files;      unsigned int fd;      int error;      struct fdtable *fdt;       spin_lock(&files->file_lock);  repeat:      fdt = files_fdtable(files);     fd = start;      if (fd < files->next_fd)          fd = files->next_fd;       if (fd < fdt->max_fds)          fd = find_next_zero_bit(fdt->open_fds->fds_bits,                         fdt->max_fds, fd);       error = expand_files(files, fd);      if (error < 0)          Goto out;             if (error)          goto repeat;       if (start <= files->next_fd)          files->next_fd = fd + 1;       FD_SET(fd, fdt->open_fds);      if (flags & O_CLOEXEC)          FD_SET(fd, fdt->close_on_exec);      else          FD_CLR(fd, fdt->close_on_exec);      error = fd;  #if 1            if (rcu_dereference(fdt->fd[fd]) != NULL) {          printk(KERN_WARNING "alloc_fd: slot %d not NULL!\n", fd);          rcu_assign_pointer(fdt->fd[fd], NULL);      }  #endif   out:      spin_unlock(&files->file_lock);      return error;  }

在pipe的系统调用中start值始终为0，而中间比较关键的expand_files()函数是根据所给的fd值，判断是否需要对进程的打开文件表进行扩容，其函数头注释如下

此处对其实现就不做深究了，回到alloc_fd()，现在可以看出，其分配fd的原则是

每次优先分配fd值最小的空闲fd，当分配不成功，即返回EMFILE的错误码，这表示当前进程中fd太多。

到此也印证了在公司写的服务端程序(kernel是2.6.18)中，每次打印client链接对应的fd值得变化规律了，假如给一个新连接分配的fd值为8，那么其关闭之后，紧接着的新的链接分配到的fd也是8，再新的链接的fd值是逐渐加1的。

为此，我继续找了一下socket对应fd分配方法，发现最终也是 alloc_fd(0, (flags)，调用序列如下
socket(sys_call) -> sock_map_fd() -> sock_alloc_fd() -> get_unused_fd_flags()
open系统调用也是用get_unused_fd_flags()，这里就不列举了。

现在想回头说说开篇的select的问题。由于Linux系统fd的分配规则，实际上是已经保证每次的fd值尽量的小，一般非IO频繁的系统，的确一个进程中fd值达到1024的概率比较小。因而对此到底是否该弃用select，还不能完全地做绝对的结论。如果设计的系统的确有其他措施保证fd值小于1024，那么用select无可厚非。

但在网络通讯程序这种场合是绝不应该作此假设的，所以还是尽量的不用select吧！！

关于Linux系统下fd分配的方法是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。