FreeBSD系统编程(6)

翻译：雨丝风片@chinaunix.net
6.1 高级I/O和进程资源
正如我们在前面章节中看到的，程序可以同时打开多个文件描述符。这些文件描述符并不一定就是文件，还可以是fifo、pipe或者socket。于是，如何复用这些打开的描述符就很重要了。例如，考虑一个简单的邮件阅读程序，比如pine。它显然应当允许用户在读写email的同时也能去检查是否有新邮件。这就意味着在任一给定时刻都至少能够接收两个来源的输入：一个来源是用户，另一个是用来检查新邮件的描述符。处理描述符的复用是个复杂的问题。一种方法是把所有打开的描述符都标记为非阻塞的（O_NONBLOCK），然后在它们之中循环，直到找到一个可以进行I/O操作的描述符为止。这种方法的问题是程序会一直在循环，如果长时间内没有I/O可用，进程就会一直占据CPU。当有多个进程在一组很少的描述符上循环时，你的CPU的负载就会恶化。
另一种方法就是设置信号处理器去捕获I/O变为可用的事件，然后就让进程进入休眠状态。如果你只打开了少量的描述符，而且并不经常请求I/O的话，这种方法从理论上看倒是不错。由于进程已经休眠，就不会再占用CPU，仅当I/O可用时它才恢复执行。然而，这种方法的问题在于信号处理的开销有点大。比如一个web服务器，每分钟收到100个请求，那就几乎一直都在捕获信号。每秒钟捕获上百个信号的开销是相当大的，不单是进程，对于内核发送信号的开销而言也是一样的。
到目前为止，我们看到的两种选择都有限制，效率也不高，它们需要解决的共同问题就是进程需要知道I/O究竟什么时候能用？然而，这个信息实际上只有内核才能事先知道，因为是内核在最终处理系统中的所有打开的描述符。例如，当一个进程通过fifo向另一个进程发送数据的时候，发送进程会调用write，这是一个系统调用，因此会进入内核。在发送方的write系统调用执行完毕之前接收方对此是一无所知的。于是就引出了一个更好的复用文件描述符的方法：由内核来替进程管理描述符。换句话说，就是把一个打开描述符的链表发送给内核，然后等待，直到内核发现某个或多个描述符已经准备好了或者已经超时了为止。
这就是select()、poll()和kqueue()接口采用的方法。通过这些接口，内核就会管理文件描述符，当I/O可用时就去唤醒进程。这些接口巧妙地处理了上述问题。进程不必再在打开的文件描述符中循环，也不必再去设置信号了。但进程在使用这些函数的时候还是会产生一点小问题。这是因为I/O操作是在从这些接口返回之后才去执行的。所以它至少需要两个系统调用才能完成其操作。例如，你的程序有两个用于读的描述符。你对它们使用select，然后等待它们直至有数据可读。这就需要进程首先调用select，在select返回之后，就对该描述符调用read。更妙的是，你还可以对所有打开的描述符执行一个整体的read。一旦其中有某个描述符准备好读之后，read就会返回，并把数据放在缓冲区中，同时还会给出一个标识，用来指示这个数据是从哪个描述符读进来的。
6.2 select
我首先要讲的接口是select()。格式如下：

int  select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,  struct timeval *timeout);传给select的第一个参数已经造成了多年的混乱。nfds参数的正确用法是把它设成文件描述符的最大值加1。换句话说，如果你有一组文件描述符{0,1,8}，nfds参数就应当被设置成9，因为你的描述符的最大值为8。有些人错误地以为这个参数的意思是文件描述符的总数加1，对于我们的例子而言就是4。记住，一个文件描述符只是一个整数而已，所以你的程序就需要指出你所想要在其上select的最大的描述符值。
select接下来会按顺序针对所有尚未完成的读、写以及异常条件检查其余的三个参数，readfds、writefds和exceptfds。（详细信息请参见man(2) select）。注意，如果readfds、writefds和execptfds中没有设置描述符，那么传给select的对应参数应当被设置成NULL。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有