高级IO

下面程序从 标准输入 读 100000 字节，并试图将它们写到 标准输出 上：

1. 将 标准输出 设置为 非阻塞 的
2. 用 轮询 进行输出

3. 每次写的结果都在 标准出错 上打印

   #include <errno.h>
   #include <fcntl.h>
   #include "apue.h"
   
   char buf[100000];
   
   int main(void)
   {
       int ntowrite, nwrite;
       char *ptr;
   
       ntowrite = read(STDIN_FILENO, buf, sizeof(buf));
       fprintf(stderr, "read %d bytes\n", ntowrite);
   
       set_fl(STDOUT_FILENO, O_NONBLOCK);  /* set nonblocking */
   
       ptr = buf;
       while (ntowrite > 0) {
           errno = 0;
           nwrite = write(STDOUT_FILENO, ptr, ntowrite);
           fprintf(stderr, "nwrite = %d, errno = %d\n", nwrite, errno);
   
           if (nwrite > 0) {
               ptr += nwrite;
               ntowrite -= nwrite;
           }
       }
   
       clr_fl(STDOUT_FILENO, O_NONBLOCK);  /* clear nonblocking */
   
       exit(0);
   }
   

     在linux上的测试结果显示并没有如想象中的调用多次非阻塞写操作，而是只有一次写操作

     虽然关于非阻塞IO内容可能已经过时，但是程序中出现的轮询却还一直被用在各种非阻塞操作中

     轮询往往会导致”浪费CPU时间“，一种更加有效的方法是使用“非阻塞描述符”的”I/O多路转接“

处理这种特殊问题的一种方法是 设置两个进程 ，每个进程处理一条数据通路。图12-2中显示了这种安排：

如果使用两个进程，则可使每个进程都执行阻塞read

但是也产生了这两个进程间相互配合问题：
1. 如果子进程接收到文件结束符(由于电话线的一端已经挂断，使调制解调器也挂断)，那么该子进程终止，然后父进程接收到SIGCHLD信号
2. 若父进程终止(用户在终端上键入了文件结束符)，那么父进程应通知子进程停止工作。为此可以使用一个信号(例如SIGUSR1)

这使程序变得更加复杂

另一个方式是仍旧 使用一个进程 执行该程序，但调用 非阻塞I/O 读取数据，其基本思想是：

• 将 两个输入描述符 都设置为 非阻塞 的
  • 对第一个描述符发一个 read
    • 如果该输入上有数据，则读数据并处理它
    • 如果无数据可读，则read立即返回
  • 对第二个描述符发一个 read 并作用样的处理
• 在此之后， 等待 若干秒 再读 第一个描述符

这种方法的不足之处是浪费CPU时间：

1. 大多数时间实际上是无数据可读，但是仍不断反复执行read，这浪费了CPU时间
2. 在每次循环后要等多长时间再执行下一轮循环也很难确定

轮询技术在支持非阻塞I/O的系统上都可使用，但是在多任务系统中应当避免使用

一种比较好的技术是使用“I/O多路转接”，其基本思想是：

1. 构造一张有关描述符的表

2. 调用一个函数，它要到这些描述符中的一个已准备好进行I/O时才返回

3. 返回时它告诉进程哪一个描述符已准备好可以进行I/O

还有一种技术称之为 异步I/O ，基本思想是进程告诉内核， 当一个描述符已准备好 可以进行I/O时，用一个 信号通知进程

这种技术有两个问题：

1. 并非所有系统都支持这种机制，现在它还不是POSIX的组成部分
SVR4为此技术提供SIGPOLL信号，但是仅当描述符引用流设备时才能工作
4.3+BSD有一个类似的信号SIGIO，但是仅当描述符引用终端设备或网络时才能工作

2. 这种信号对每个进程而言只有1个
如果使该信号对两个描述符都起作用，那么在接到此信号时进程无法判别是哪一个描述符已准备好可以进行I/O
为了确定是哪一个描述符已准备好，仍需将这两个描述符都设置为非阻塞的，并顺序尝试执行I/O

系统只是告诉某个事件发生在文件描述符，但并不告诉关于文件描述符状态变化的任何信息，仍然需要主动地使用select或poll来查询描述符状态

iovec结构 用来说明 缓存区 ：

struct iovec
{
    void *iov_base;    /* 缓冲区起始地址 */
    size_t iov_len;    /* 缓冲区长度 */
}

下图显示了readv和writev的参数和iovec结构之间的关系：

• writev: 顺序 iov[0] ， iov[1] 至 iov[iovcnt-1] 从 缓存 中 聚集 输出数据 +返回： 输出的字节总数 ，等于 各个缓存长度之和
• readv: 将 读入的数据 按上述同样 顺序 散布 到 缓存 中
  • 总是先填满一个缓存，然后再填写下一个
  • 返回：读得的 总字节数
    • 如果遇到 文件结尾 ，已无数据可读，则返回 0

有三种方法可以实现从两个缓存区写入一个文件:

1. 调用 write两次 ，一次一个缓存
2. 分配 一个大到 足以包含两个缓存的新缓存 。将两个缓存的内容 复制到新缓存中 。然后对该缓存调用wrtre一次
3. 调用 writev 输出两缓存

     测试结果显示：

     调用两次write几乎是另外两种方法的2倍时间

     采用缓存复制后用一个write与采用一个writev所用CPU时间几乎一样
     但一般说来，因为前者还需要分配一个临时缓存用于存储及复制，所以后者更复杂

mmap 函数：*告诉* 内核 将一个给定的 文件 映射 到一个 存储区域 中

#include <sys/types.h>
#include <sys/mman.h>

/**
 * 磁盘文件映射到内存中的缓冲区
 *
 * addr: 缓存区的首地址，一般为NULL，表示系统自己分配，应为系统“虚拟内存页的整数倍”
 * len: 缓存区长度
 * prot: 文件保护模式，PROT_NONE, PROT_READ, PROT_WRITE, PROT_EXEC的任意或逻辑的组合
 * flag: MAP_FIXED 要求系统使用指定的 addr,不建议使用此标志
 *       MAP_SHARED 修改缓冲区即为直接修改文件
 *       MAP_PRIVATE(缓冲区仅仅是文件的副本
 * filedes: 文件描述符
 * off: 文件中的起始位置，应为系统“虚拟内存页的整数倍”
 *
 * return：若成功则返回“映射区的起始地址”，若出错则为 -1
 *
 */
void *mmap(void *addr, size_t len, int prot, int flag, int filedes, off_t off);

munmap 函数： 解除 内存映射

#include <sys/types.h>
#include <sys/mman.h>

/**
 * 解除存储映射
 *
 * addr : 缓存区首地址
 * len : 缓存区长度
 *
 * return : 若成功则为 0，若出错则为 -1
 */
int munmap(caddr_t addr, size_t len);

进程终止 时或 调用了munmap 之后， 存储映射区 就被 自动去除

      注意：“关闭文件描述符”filedes并不“解除映射区”

     调用munmap并不使映射区的内容写到磁盘文件上

调用 msync 函数才使 修改后的数据 反应到 映射的 磁盘文件 中　

#include <sys/types.h>
#include <sys/mman.h>

/**
 * 使修改后的数据更新到映射的磁盘文件中
 *
 * addr : 映射缓存区首地址
 * len : 映射缓存区长度
 * flags : 更新方式 MS_ASYNC(异步更新，立即返回)，MS_SYNC(同步更新，更新完成后才返回)
 *
 */
void msync(void *addr, size_t len, int flags);

下面程序用 存储映射 I/O 复制 一个 文件 ：

1. 打开 两个文件
2. 调用 fstat 得到 输入文件的长度
3. 调用 lseek ，然后 写一个字节 以 设置 输出文件的长度
   • 如果不设置输出文件的长度，则对输出文件调用mmap也可以，但是 对相关存储区的第一次存访 会 产生 SIGBUS
4. 对每个文件调用 mmap ，将文件 映射 到存储区
5. 调用 memcpy 将 输入缓存的内容 复制 到 输出缓存
   • 在从 输入缓存 取 数据字节时， 内核 自动读 输入文件
   • 在将 数据 存入 输出缓存 时， 内核 自动将数据写 到 输出文件 中

     也可使用'ftruncate'函数来设置输出文件的长度，但是并非所有系统都支持该函数扩充文件长度

#include "apue.h"
#include <fcntl.h>
#include <sys/mman.h>

int main(int argc, char *argv[])
{
    int         fdin, fdout;
    void        *src, *dst;
    struct stat statbuf;

    if (argc != 3)
        err_quit("usage: %s <fromfile> <tofile>", argv[0]);

    if ((fdin = open(argv[1], O_RDONLY)) < 0)
        err_sys("can't open %s for reading", argv[1]);

    if ((fdout = open(argv[2], O_RDWR | O_CREAT | O_TRUNC,
              FILE_MODE)) < 0)
        err_sys("can't creat %s for writing", argv[2]);

    if (fstat(fdin, &statbuf) < 0)  /* need size of input file */
        err_sys("fstat error");

    /* set size of output file */
    if (lseek(fdout, statbuf.st_size - 1, SEEK_SET) == -1)
        err_sys("lseek error");
    if (write(fdout, "", 1) != 1)
        err_sys("write error");

    if ((src = mmap(0, statbuf.st_size, PROT_READ, MAP_SHARED,
            fdin, 0)) == MAP_FAILED)
        err_sys("mmap error for input");

    if ((dst = mmap(0, statbuf.st_size, PROT_READ | PROT_WRITE,
            MAP_SHARED, fdout, 0)) == MAP_FAILED)
        err_sys("mmap error for output");

    memcpy(dst, src, statbuf.st_size);  /* does the file copy */
    exit(0);
}

测试：

#使用cp和mmap拷贝一个1.2G长度的文件
$ time cp ~/Movie/La\ La\ Land/La\ La\ Land.mkv ./ 

real    0m23.824s
user    0m0.010s
sys     0m2.170s

$ time ./mcopy ~/Movie/La\ La\ Land/La\ La\ Land.mkv ./a.mkv

real    0m16.796s
user    0m0.186s
sys     0m1.079s

     测试结果显示：将一个普通文件复制到另一个普通文件中时，存储映射I/O比较快

     但是有一些限制，如不能用在某些设备之间(例如网络设备或终端设备)进行复制
     并且对被复制的文件进行映射后，也要注意该文件的长度是否改变

     尽管如此有很多应用程序会从存储映射I/O得到好处
     因为它处理的是内存而不是读、写一个文件，所以常常可以“简化算法”

下面表列出了各种UNIX系统提供的不同形式的记录锁：

POSIX.1选择了以 fcntl 函数为基础的 系统V风格 的 记录锁，  这种风格也得到4.3BSDReno版本的支持： 

fcntl函数可以锁 文件中的任一区域 ，大至整个文件，小至单个字节
早期的伯克利版只支持 flock 函数，此函数只 锁整个文件，而不锁文件中的一个区域
系统V的 lockf 函数只是 fcntl 函数的一个接口

     前面已经给出了fcntl函数的原型

#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>

/**
 * 改变已经打开文件的性质
 *
 * filedes : 文件描述符
 * cmd : 功能
 * args : 可选参数
 *
 * return : 成功依赖于 cmd，失败 -1
 *
 */
int fcntl(int filedes, int cmd, .../* int arg*/);

对于记录锁：

• cmd ：
  1. F_GETLK
  2. F_SETLK
  3. F_SETLKW
• 第三个参数 flockptr ：一个指向 flock结构 的指针

关于记录锁的 自动继承 和 释放 有三条规则:

• 锁 与 进程 、 文件 两方面有关：
  1. 当一个 进程终止 时，它所建立的 锁全部释放
  2. 任何时候 关闭一个描述符 时，则 该进程 通过这个 描述符可以存访的文件 上的 任何一把锁 都被 释放 (这些锁都是该进程设置的)

如果执行下列四步:

fd1 = open(pathname /*, ...*/);
read_lock(fd1 /*, ...*/);
fd2 = dup(fd1) ;
close(fd2) ;

则在close(fd2)后，在fd1上设置的锁被释放。如果将dup代换为open，其效果也一样:

fd1 = open(pathname /*, ...*/);
read_lock(fd1 /*, ...*/);
fd2 = open(fd1) ;
close(fd2) ;

• 由 fork 产生的 子程序 不继承 父进程 所设置的锁

     若一个进程得到一把锁，然后调用fork，那么对于父进程获得的锁而言，子进程被视为另一个进程

     对于从父进程处继承过来的任一描述符，子进程要调用fcntl以获得它自己的锁

     如果子进程继承父进程的锁，则父、子进程就可以同时写同一个文件，而锁的作用就是为了阻止多个进程同时写同一个文件(或同一文件区域)

• 在执行 exec 后， 新程序 可以 继承 原执行程序的锁

考虑一个进程，它执行下列语句(忽略出错返回)：

fd1 = open(pathname/*,...*/);
write_lock(fd1, 0, SEEK_SET, 1); /*parent write locks byte 0*/
if(fork() > 0) { /*parent*/
    fd2 = dup(fd1);
    fd3 = open(pathname/*,...*/);
    pause();
} else {
    read_lock(fd1, 1, SEEK_SET, 1); /*child read locks byte 1*/
    pause();
}

图12-1显示了父、子进程暂停(执行pause())后的数据结构情况：

有了记录锁后，在原来的这些图上 新加 了 flock结构 ，它们由 i节点结构 开始 相互连接 起来

     注意：每个flock结构说明了一个给定进程的一个加锁区域

图中显示了两个 flock 结构，每一个结构都 包含 了相应 进程ID ：

• 由 父进程 调用 write_lock 形成的
• 由 子进程 调用 read_lock 形成的

       在父进程中关闭fd1、fd2和fd3中的”任意一个“都将释放由”父进程设置的写锁“

       在关闭这三个描述符中的”任意一个“时，内核会从该描述符所关连的i节点开始逐个检查flock连接表中各项，并释放由调用进程持有的各把锁

       内核并不清楚也不关心“父进程是用哪一个描述符”来设置“这把锁“

     考虑数据库存取例程序：

     如果该库中所有函数都以一致的方法处理记录锁，则称使用这些函数存取数据库的任何进程集为“合作进程”

     如果这些函数是唯一的用来存取数据库的函数，那么它们使用“建议性锁”是可行的

     但是建议性锁并不能阻止对数据库文件有写许可权的任何其他进程写数据库文件

     不使用协同一致的方法来存取数据库的进程是一个非合作进程

强制性锁 机制中， 内核 对每一个 open 、 read 和 write 都要 检查 调用进程对 正在存取的文件 是否违背 了某一把锁的作用

SVR4实现中：

对一个特定文件打开其“设置-组-ID位，关闭其组-执行位”则对该文件“启动了强制性锁”机制

因为当组-执行位关闭时，设置-组-ID位不再有意义，所以设计者借用两者的这种组合来指定对一个文件的锁是强制性的而非建议性的

如果一个进程试图 读 、 写 一个 强制性锁 起作用的文件，而欲读、写的部分又由其他进程加上了读、写锁，此时会发生什么呢？这一问题的回答取决于三方面的因素:

• 操作类型 ：read或write
• 其他进程保有的 锁的类型 ：读锁或写锁

• 有关 描述符 是 阻塞 还是 非阻塞 的

  区域上的锁	阻塞描述符		非阻塞描述符
  	读	写	读	写
  强制性读锁	可以	阻塞	可以	EAGAIN
  强制性写锁	阻塞	阻塞	EAGAIN	EAGAIN

除了表中的read，write函数，其他进程的强制性锁也会对 open 函数产生影响。通常即使正在打开的文件具有强制性记录锁，该打开操作也会成功，接下来的read或write依从于中所示的规则

     但是如果欲打开的文件具有强制性锁(读锁或写锁)，而且open调用中的flag为O_TRUNC或O_CREAT
     则不论是否指定O_NONBLOCK，open都立即出错返回，errno设置为EAGAIN

     对O_TRUNC情况出错返回是有意义的，因为其他进程对该文件持有读、写锁，所以不能将其截短为0

     对O_CREAT情况在返回时也设置errno则无意义，因为该标志的意义是如果该文件不存在则创建
     由于其他进程对该文件持有记录锁，因而该文件肯定是存在的

这种处理方式可能导致令人惊异的结果

例如 某个程序 打开一个文件，其模式指定为 强制性锁 ，然后对 该文件的整体 设置 一把读锁

然后进入 睡眠 一段时间。在这段睡眠时间内，用某些常规的UNIX程序和操作符对该文件进行处理，发现下列情况:

可用 ed 编辑程序对该文件进行 编辑 操作，而且编辑 结果可以写回磁盘 。对ed操作进行跟踪分析发现：
1. ed将新内容写到一个临时文件中
2. 删除原文件
3. 将临时文件名改名为原文件名
因此强制性锁机制对unlink函数没有影响

不能用 _vi_ 编辑程序编辑该文件。vi可以读该文件，但是如果试图将新的数据写到该文件中，则出错返回(EAGAIN)
如果试图将新数据添加到该文件中，则write阻塞。vi的这种行为与所希望的一样

使用KornShell的 '>' 和 '>>' 运算符重写或添写到该文件中，产生出错信息 'cannotcreat' 
在Bourneshell下使用 '>' 运算符出错，但是使用 '>>' 算符则“阻塞”，在删除了强制性锁后再继续进行处理

执行添加操作所产生的区别是因为:
KornShell以O_CREAT和O_APPEND标志打开文件，而上面已提及指定O_CREAT会产生出错返回
Bourneshell在该文件已存在时并不指定O_CREAT，所以open成功，而下一个write则阻塞

使用强制性锁的时候必须小心谨慎

     一个别有用心的用户可以对大家都可读的文件加一把读锁(强制性)，这样就能阻止任何其他人写该文件

     当然该文件应当是强制性锁机制起作用的，这可能要求该用户能够更改该文件的许可权位