2.1. 如何管理多个连接？
“我想同时监控一个以上的文件描述符(fd)/连接(connection)/流(stream)，
应该怎么办？”
使用 select() 或 poll() 函数。
注
意：select() 在BSD中被引入，而poll()是SysV STREAM流控制的产物。因此，这里就有了平台移植上的考虑：纯粹的BSD系统可
能仍然缺少poll()，而早一些的SVR3系统中可能没有select()，尽管在SVR4中将其加入。目前两者都是POSIX. 1g标准，（译者
注：因此在Linux上两者都存在）
select()和poll()本质上来讲做的是同一件事，只是完成的方法不一样。两者都通过检
验一组文件描述符来检测是否有特定的时间将在上面发生并在一定的时间内等待其发生。
[重要事项：无论select()还是poll()
都不对普通文件起很大效用，它们着重用于套接口(socket)、管道(pipe)、伪终端(pty)、终端设备(tty)和其他一些字符设备，但是这些
操作都是系统相关(system-dependent)的。]
2.1.1. 我如何使用select()函数？
select()
函数的接口主要是建立在一种叫'fd_set'类型的基础上。它('fd_set') 是一组文件描述符(fd)的集合。由于fd_set类型的长度在不
同平台上不同，因此应该用一组标准的宏定义来处理此类变量：
fd_set set;
FD_ZERO(&set); /* 将
set清零 */
FD_SET(fd, &set); /* 将fd加入set */
FD_CLR(fd, &set); /* 将
fd从set中清除 */
FD_ISSET(fd, &set); /* 如果fd在set中则真 */
在
过去，一个fd_set通常只能包含少于等于32个文件描述符，因为fd_set其实只用了一个int的比特矢量来实现，在大多数情况下，检查
fd_set能包括任意值的文件描述符是系统的责任，但确定你的fd_set到底能放多少有时你应该检查/修改宏FD_SETSIZE的值。*这个值是系
统相关的*，同时检查你的系统中的select() 的man手册。有一些系统对多于1024个文件描述符的支持有问题。[译者注： Linux就是这样
的系统！你会发现sizeof(fd_set)的结果是128(*8 = FD_SETSIZE=1024) 尽管很少你会遇到这种情况。]
select
的基本接口十分简单：
int select(int nfds, fd_set *readset, fd_set *writeset,
fd_set *exceptset, struct timeval *timeout);
其
中：
nfds
需要检查的文件描述符个数，数值应该比是三组fd_set中最大数
更大，
而不是实际文件描述符的总数。
readset
用来检查可读性的一组文件描述符。
writeset
用
来检查可写性的一组文件描述符。
exceptset
用来检查意外状态的文件描述符。(注：错误并不是意外状态)
timeout
NULL
指针代表无限等待，否则是指向timeval结构的指针，代表最
长等待时间。(如果其中tv_sec和tv_usec都等于0, 则文
件描述符
的状态不被影响，但函数并不挂起)
函数将返回响应操作的对应操作文件描述符的总数，且三组数据均
在恰当位置被修改，只有响应操作的那一些没有修改。接着应该用FD_ISSET宏来查找返回的文件描述符组。
这里是一个简单的测试单个
文件描述符可读性的例子：
int isready(int fd)
{
int rc;
fd_set fds;
struct timeval tv;
FD_ZERO(&fds);
FD_SET(fd,&fds);
tv.tv_sec = tv.tv_usec = 0;
rc = select(fd+1, &fds, NULL, NULL, &tv);
if (rc < 0)
return -1;
return FD_ISSET(fd,&fds) ? 1 : 0;
}
当
然如果我们把NULL指针作为fd_set传入的话，这就表示我们对这种操作的发生不感兴趣，但select() 还是会等待直到其发生或者超过等待时
间。
[译
者注：在Linux中，timeout指的是程序在非sleep状态中度过的时间，而不是实际上过去的时间，这就会引起和非Linux平台移植上的时间不
等问题。移植问题还包括在System V风格中select()在函数退出前会把timeout设为未定义的 NULL状态，而在BSD中则不是这样，
Linux在这点上遵从System V，因此在重复利用timeout指针问题上也应该注意。]
2.1.2. 我如何使用
poll()？
poll
()接受一个指向结构'struct pollfd'列表的指针，其中包括了你想测试的文件描述符和事件。事件由一个在结构中事件域的比特掩码确定。当前
的结构在调用后将被填写并在事件发生后返回。在SVR4(可能更早的一些版本)中的 "poll.h"文件中包含了用于确定事件的一些宏定义。事件的等待
时间精确到毫秒 (但令人困惑的是等待时间的类型却是int)，当等待时间为0时，poll()函数立即返回，-1则使poll()一直挂起直到一个指定
事件发生。下面是pollfd的结构。
struct pollfd {
int fd; /* 文
件描述符 */
short events; /* 等待的事件 */
short revents; /* 实
际发生了的事件 */
};
于select()十分相似，当返回正值时，代表满足响应事件的文件描述符的个
数，如果返回0则代表在规定事件内没有事件发生。如发现返回为负则应该立即查看 errno，因为这代表有错误发生。
如果没有事件发
生，revents会被清空，所以你不必多此一举。
这里是一个例子
/* 检测两个文件描述符，分别为一般数据
和高优先数据。如果事件发生
则用相关描述符和优先度调用函数handler()，无时间限制等待，直到
错误发生
或描述符挂起。*/
#include
#include
#include
#include
#include
#include
#include
#include
#define NORMAL_DATA 1
#define HIPRI_DATA 2
int poll_two_normal(int fd1,int fd2)
{
struct pollfd poll_list[2];
int retval;
poll_list[0].fd = fd1;
poll_list[1].fd = fd2;
poll_list[0].events = POLLIN|POLLPRI;
poll_list[1].events = POLLIN|POLLPRI;
while(1)
{
retval = poll(poll_list,(unsigned long)2,-1);
/* retval 总
是大于0或为-1，因为我们在阻塞中工作 */
if(retval < 0)
{
fprintf(stderr,"poll
错误: %s\n",strerror(errno));
return -1;
}
if(((poll_list[0].revents&POLLHUP) == POLLHUP) ||
((poll_list[0].revents&POLLERR) == POLLERR) ||
((poll_list[0].revents&POLLNVAL) == POLLNVAL) ||
((poll_list[1].revents&POLLHUP) == POLLHUP) ||
((poll_list[1].revents&POLLERR) == POLLERR) ||
((poll_list[1].revents&POLLNVAL) == POLLNVAL))
return 0;
if((poll_list[0].revents&POLLIN) == POLLIN)
handle(poll_list[0].fd,NORMAL_DATA);
if((poll_list[0].revents&POLLPRI) == POLLPRI)
handle(poll_list[0].fd,HIPRI_DATA);
if((poll_list[1].revents&POLLIN) == POLLIN)
handle(poll_list[1].fd,NORMAL_DATA);
if((poll_list[1].revents&POLLPRI) == POLLPRI)
handle(poll_list[1].fd,HIPRI_DATA);
}
}
2.1.3. 我
是否可以同时使用SysV IPC和select()/poll()？
*不能。* (除非在AIX上，因为它用一个无比奇怪的方法来实现这种组
合)
一般来说，同时使用select()或poll()和SysV 消息队列会带来许多麻烦。SysV IPC的对象并不是用文件描述
符来处理的，所以它们不能被传递给select()和 poll()。这里有几种解决方法，其粗暴程度各不相同：
完全放弃使用
SysV IPC。 :-)
用fork()，然后让子进程来处理SysV IPC，然后用管道或套接口和父进程 说话。父进程则使用
select()。
同上，但让子进程用select()，然后和父亲用消息队列交流。
安排进程发送消息给你，在发送
消息后再发送一个信号。*警告*：要做好 这个并不简单，非常容易写出会丢失消息或引起死锁的程序。
另外还有其他方法。
poll :
|
||
| 驱动中poll_wait()函数的疑问 应用程序的 select()系统调用，调用驱动中的poll()方法。 不理解的是在下面的poll()方法实现中，首先调用poll_wait将等待队列添 加到wait结构中，接下来是个判断语句 if (dev->rp != dev->wp) mask |= POLLIN | POLLRDNORM; /* readable */ 只 考虑可读情况。如果这个if语句的条件不满足，那么就不会返回可读，也就是返回0。那么在这里怎么实现阻塞的呢？也就是说如果在应用的select()系 统中，指定一个等待时间，在这个等待时间里如果没有描述符可读，就一直阻塞。那个这个等待时间是怎么和驱动中的poll()方法联系起来的呢？如果要修改 这个poll()方法怎么修改呢？还有在poll()方法中，怎么指定描述符集中的哪一个是可读的呢？简单的返回POLLIN | POLLRDNORM，是无法指定是哪一个描述符可读的呀？ static unsigned int scull_p_poll(struct file *filp, poll_table *wait) { struct scull_pipe *dev = filp->private_data; unsigned int mask = 0; /* * The buffer is circular; it is considered full * if "wp" is right behind "rp" and empty if the * two are equal. */ down(&dev->sem); poll_wait(filp, &dev->inq, wait); // poll_wait(filp, &dev->outq, wait); if (dev->rp != dev->wp) mask |= POLLIN | POLLRDNORM; /* readable */ //if (spacefree(dev)) // mask |= POLLOUT | POLLWRNORM; /* writable */ up(&dev->sem); return mask; } |
|
||
| 在调用驱动程序的poll之前，实现调用VFS相关的poll接口的（比如sys_poll等），阻塞、等待时间等 的实现是在那个里面完成的 |
|
||
| 那么驱动的这个poll()方法总是立刻返回的？ |
|
||
| 对啊 |
|
||
| 是立刻返回的，那么如果有一个描述符集当前不可读，也就返回0。但等了一段时间后可读，那么怎么返回mask |=
POLLIN | POLLRDNORM;。我的意思是怎么指示给应用程序可读的呢？ 那么驱动的poll()方法的作用是什么呢？ |
|
||
| 如果当前不可读，那么在sys_poll->do_poll中当
前进程就会睡眠在等待队列上，这个等待队列是由驱动程序提供的（就是poll_wait中传入的那个）。当可读的时候，驱动程序可能有一部分代码运行了
（比如驱动的中断服务程序），那么在这部分代码中，就会唤醒等待队列上的进程，也就是之前睡眠的那个，当那个进程被唤醒后do_poll会再一次的调用驱
动程序的poll函数，这个时候应用程序就知道是可读的了。 不知道有没有解释清楚啊，呵呵 |
|
||
| 非常感谢。 |
|
||
| POOL方法就是用来支持非阻塞式的访问，当然是立即返回，但是它会把这次请求放入一个等待队列中，当某个条件满足 时，内核会通知应用程序（应用程序的select函数会感知），然后就会接着select操作 |