select(poll)分析背景

  我们编写驱动程序的时候，通常需要告诉上层应用程序设备的状态：是否可读写。
  应用程序可以直接通过read/write系统调用(阻塞和非阻塞模式)进入内核态驱动程序，那么驱动程序的read/write至少需要支持阻塞和非阻塞模式的读写：
  上层阻塞模式调用read时，如果设备驱动的read_buffer中没有数据可以供上层读取,就让该进程睡眠(阻塞)直到有数据才被唤醒，然后取到数据返回用户态；如果是非阻塞模式调用read时，read_buffer中没有数据直接返回0。
  上层阻塞模式调用write时，如果设备驱动的write_buffer已满没有空间写入数据，就让该进程睡眠(阻塞)直到write_buffer中有空间可以写入数据才被唤醒，然后将数据写入write_buffer后返回用户态；如果是非阻塞模式调用write时，write_buffer中没有空间直接返回0。
  
  如果一个应用程序需要同时访问多个硬件设备，此时就不能使用阻塞模式打开设备了，否则整个进程可能就阻塞在了某个硬件上。这种情况可以采用如下异步的方式：有数据可读返回数据个数，没有返回0或者-1，应用程序每隔一段时间就对依次各个设备进行读取，对单个设备来说有数据就返回数据，没有就返回0，当所有设备遍历完之后，继续睡眠，时间间隔到再唤醒继续这样的动作。这样进程反复睡眠唤醒对系统效率影响很大。
  
  对于这个问题，linux提供了另外一个方法，select和poll的方式: 这种方式下，应用程序将轮询进程所有设备文件描述符的工作交给了操作系统，这样应用程序中只需阻塞在select或者poll系统调用中，返回后，肯定至少有一个设备文件描述符的状态有发生改变，要不然该应用进程的阻塞是不会退出的。
  
  
  本次研究主要问题集中在：
  select和poll系统调用在应用程序中如何使用？
  select和poll系统调用中如何实现同时监测多个设备文件描述符？