write的返回值read/write
read 函数从打开的设备或文件中读取数据。
#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count); 返回值：成功返回读取的字节数，出错返回-1 并设置 errno，如果在调 read 之前已到达文件末尾，则这次 read 返回 0
参数 count 是请求读取的字节数，读上来的数据保存在缓冲区 buf 中，同时文件 的当前读写位置向后移。 注意这个读写位置和使用 C 标准 I/O 库时的读写位置有 可能不同， 这个读写位置是记在内核中的， 而使用 C 标准 I/O 库时的读写位置是 用户空间 I/O 缓冲区中的位置。比如用 fgetc 读一个字节，fgetc 有可能从内核 中预读 1024 个字节到 I/O 缓冲区中，再返回第一个字节，这时该文件在内核中 记录的读写位置是 1024，而在 FILE 结构体中记录的读写位置是 1。注意返回值 类型是 ssize_t，表示有符号的 size_t，这样既可以返回正的字节数、0（表示 到达文件末尾）也可以返回负值-1（表示出错）。read 函数返回时，返回值说 明了 buf 中前多少个字节是刚读上来的。有些情况下，实际读到的字节数（返回 值）会小于请求读的字节数 count，例如： 读常规文件时，在读到 count 个字节之前已到达文件末尾。例如， 距文件末尾还有 30 个字节而请求读 100 个字节， read 返回 30， 则 下次 read 将返回 0。 • 从终端设备读，通常以行为单位，读到换行符就返回了。 • 从网络读，根据不同的传输层协议
和内核缓存机制，返回值可能小 于请求的字节数，后面 socket 编程部分会详细讲解。
•
write 函数向打开的设备或文件中写数据。
#include <unistd.h>
ssize_t write(int fd, const void *buf, size_t count); 返回值：成功返回写入的字节数，出错返回-1 并设置 errno
写常规文件时，write 的返回值通常等于请求写的字节数 count，而向终端设备 或网络写则不一定。 读常规文件是不会阻塞的，不管读多少字节，read 一定会在有限的时间内返回。 从终端设备或网络读则不一定，如果从终端输入的数据没有换行符，调用 read 读终端设备就会阻塞，如果网络上没有接收到数据包，调用 read 从网络读就会 阻塞， 至于会阻塞多长时间也是不确定的，如果一直没有数据到达就一直阻塞在 那里。同样，写常规文件是不会阻塞的，而向终端设备或网络写则不一定。 现在明确一下阻塞（Block）这个概念。当进程调用一个阻塞的系统函数时，该 进程被置于睡眠（Sleep）状态，这时内核调度其它进程运行，直到该进程等待 的事件发生了 （比如网络上接收到数据包， 或者调用 sleep 指定的睡眠时间到了） 它才有可能继续运行。与睡眠状态相对的是运行（Running）状态，在 L
inux 内 核中，处于运行状态的进程分为两种情况： 正在被调度执行。CPU 处于该进程的上下文环境中，程序计数器 （eip）里保存着该进程的指令地址，通用寄存器里保存着该进程 运算过程的中间结果，正在执行该进程的指令，正在读写该进程的 地址空间。 • 就绪状态。该进程不需要等待什么事件发生，随时都可以执行，但 CPU 暂时还在执行另一个进程，所以该进程在一个就绪队列中等 待被内核调度。 系统中可能同时有多个就绪的进程，那么该调度谁 执行呢？内核的调度算法是基于优先级和时间片的， 而且会根据每 个进程的运行情况动态调整它的优先级和时间片， 让每个进程都能 比较公平地得到机会执行，同时要兼顾用户体验，不能让和用户交 互的进程响应太慢。
•
下面这个小程序从终端读数据再写回终端。 例 28.2. 阻塞读终端
#include <unistd.h> #include <stdlib.h>
int main(void) { char buf[10]; int n;
n = read(STDIN_FILENO, buf, 10); if (n < 0) { perror("read STDIN_FILENO"); exit(1); } write(STDOUT_FILENO, buf, n); return 0; }
执行结果如下：
$ ./a.out hello（回车） hello $ ./a.out hello world（回车） hello worl$ d bash: d: command not found
第一次执行 a.out 的结果很正常， 而第二次执行的过程有点特殊， 现在分析一下： 1. Shell 进程创建 a.out 进程，a.out 进程开始执行，而 Shell 进程睡 眠等待 a.out 进程退出。 2. a.out 调用 read 时睡眠等待， 直到终端设备输入了换行符才从 read 返回，read 只读走 10 个字符，剩下的字符仍然保存在内核的终端 设备输入缓冲区中。 3. a.out 进程打印并退出，这时 Shell 进程恢复运行，Shell 继续从终 端读取用户输入的命令， 于是读走了终端设备输入缓冲区中剩下的
字符 d 和换行符， 把它当成一条命令解释执行， 结果发现执行不了， 没有 d 这个命令。 如果在 open 一个设备时指定了 O_NONBLOCK 标志，read/write 就不会阻塞。以 read 为例，如果设备暂时没有数据可读就返回-1，同时置 errno 为 EWOULDBLOCK （或者 EAGAIN，这两个宏定义的值相同），表示本来应该阻塞在这里（would block，虚拟语气），事实上并没有阻塞而是直接返回错误，调用者应该试着再 读一次（again）。这种行为方式称为轮询（Poll），调用者只是查询一下，而 不是阻塞在这里死等，这样可以同时监视多个设备：
while(1) { 非阻塞 read(设备 1); if(设备 1 有数据到达) 处理数据; 非阻塞 read(设备 2); if(设备 2 有数据到达) 处理数据; ... }
如果 read(设备 1)是阻塞的， 那么只要设备 1 没有数据到达就会一直阻塞在设备 1 的 read 调用上，
即使设备 2 有数据到达也不能处理，使用非阻塞 I/O 就可以 避免设备 2 得不到及时处理。 非阻塞 I/O 有一个缺点，如果所有设备都一直没有数据到达，调用者需要反复查 询做无用功，如果阻塞在那里，操作系统可以调度别的进程执行，就不会做无用 功了。在使用非阻塞 I/O 时，通常不会在一个 while 循环中一直不停地查询（这 称为 Tight Loop），而是每延迟等待一会儿来查询一下，以免做太多无用功，在 延迟等待的时候可以调度其它进程执行。
while(1) { 非阻塞 read(设备 1); if(设备 1 有数据到达) 处理数据;
非阻塞 read(设备 2); if(设备 2 有数据到达) 处理数据; ... sleep(n); }
这样做的问题是，设备 1 有数据到达时可能不能及时处理，最长需延迟 n 秒才 能处理，而且反复查询还是做了很多无用功。以后要学习的 select(2)函数可以 阻塞地同时监视多个设备， 还可以设定阻塞等待的超时时间，从而圆满地解决了 这个问题。 以下是一个非阻塞 I/O 的例子。目前我们学过的可能引起阻塞的设备只有终端， 所以我们用终端来做这个实验。程序开始执行时在 0、1、2 文件描述符上自动 打开的文件就是终端，但是没有 O_NONBLOCK 标志。所以读标准输入是阻塞的。 我们可以重新打开一遍设备文件/dev/tty（表示当前终端），在打开时指定 O_NONBLOCK 标志。 例 28.3. 非阻塞读终端
#include <unistd.h> #include <fcntl.h> #include <errno.h> #include <string.h> #include <stdlib.h>
#define MSG_TRY "try again\n"
int main(void) { char buf[10];

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。