你所不知道的linux匿名管道知识详解
相信很多在linux平台工作的童鞋, 都很熟悉管道符 '|', 通过它, 我们能够很灵活的将几种不同的命令协同起来完成一件任务。就好像下面的命令:
不过这次咱们不来说这些用法, 而是来探讨一些更加有意思的, 那就是管道两边的数据流实时性和管道使用的小提示。
其实我们在利用管道的时候, 可能会不经意的去想, 我前一个命令的输出, 是全部处理完再通过管道传给第二个命令, 还是一边处理一边输出呢? 可能在大家是试验中或者工作经验中, 应该是左边的命令全部处理完再一次性交给右边的命令进行处理, 不光是大家, 我在最初接触管道时, 也曾有这么一个误会, 因为我们通过现象看到的就是这样。
但其实只要有简单了解过管道这工具, 应该都不难得出解释:
管道是两边是同时进行, 也就是说, 左边的命令输出到管道, 管道的右边将马上进行处理。
管道的定义
管道是由内核管理的一个缓冲区，相当于我们放入内存中的一个纸条。管道的一端连接一个进程的输出。这个进程会向管道中放入信息。管道的另一端连接一个进程的输入，这个进程取出被放入管道的信息。一个缓冲区不需要很大，它被设计成为环形的数据结构，以便管道可以被循环利用。当管道中没有信息的话，从管道中读取的进程会等待，直到另一端的进程放入信息。当管道被放满信息的时候，尝试放入信息的进程会堵塞，直到另一端的进程取出信息。当两个进程都终结的时候，管道也自动消失。
管道工作流程图
通过上面的解释可以看到, 假设 command1 | command2, 那么command1的标准输出, 将会被绑定到管道的写端, 而command2的标准输入将会绑定到管道的读端, 所以当command1一有输出, 将会马上通过管道传给command2, 我们先来做个实验验证下:
在上面的命令, 我们可以猜测下输出结果: 究竟是 睡眠6秒之后, 输出1111222, 还是输出 1111 睡眠3秒, 再输出 2222, 然后再睡眠3秒, 再输出1111 呢? 答案就是: 都不是! what! 这不可能, 大家可以尝试下, 我们会看到终端没反应了, 为什么呢? 这就要涉及到文件io的缓冲方式了，这里不多说, 简单提一下文件io的三种缓冲方式:
全缓冲:直到缓冲区被填满，才调用系统i/o函数, (一般是针对文件)
行缓冲: 遇到换行符就输出(标准输出)
无缓冲:没有缓冲区，数据会立即读入或者输出到外存文件和设备上(标准错误
因为python是默认采用带缓冲的fputs,又因为标准输出被改写到管道, 所以将会采取全缓冲的方式(shell 命令具体要看实现, 因为有些是用不带缓冲write实现,如果不带缓冲区,会直接写入管道), 所以将会采取全缓冲的方式, 也就是说, 直到缓冲区被填满, 或者手动显示调用flush刷入,才能看到输出。那我们可以将代码改写成下面两种方式吧
输出结果:
在这里我们已经能够得出结果, 如果像我们以前所想的那样, 要等到command1全部执行完才一次性输出给command2, 那么结果应该是无限堵塞。因为我的程序一直没有执行完。这样应该是不符合老前辈们设计初衷的, 因为这样可能会导致管道越来越大。然而管道也是有大小的~ 具体可以去看posix标准, 所以我们得出结论是: 只要command1的输出写入管道的写端(不管是缓冲区满还是手动flush), command2都将立刻得到数据并且马上处理。
那么管道两边的数据流实时性讨论到就先暂告一段落, 接下来将在这个基础上继续讨论:管道使用的小提示。
在开始讨论前, 我想先引入一个专业术语, 也是我们偶尔会遇到的, 那就是:sigpipe。
或者是一个更加具体的描述:broken pipe(管道破裂)
上面的专业术语都是跟管道读写规则息息相关的, 那咱们来看下 管道的读写规则吧:
1.当没有数据可读时
o_nonblock (未设置)：read调用阻塞，即进程暂停执行，一直等到有数据来到为止。
o_nonblock ( 设置 ) ：read调用返回-1，errno值为eagain。
2.当管道满的时候
o_nonblock (未设置)： write调用阻塞，直到有进程读走数据
o_nonblock ( 设置 )：调用返回-1，errno值为eagain
3.如果所有管道写端对应的文件描述符被关闭，则read返回0
4.如果所有管道读端对应的文件描述符被关闭，则write操作会产生信号sigpipe
5.当要写入的数据量不大于pipe_buf时，linux将保证写入的原子性。
6.当要写入的数据量大于pipe_buf时，linux将不再保证写入的原子性。
在上面我们可以看到, 如果我们收到sigpipe信号, 那么一般情况就是读端被关闭, 但是写端却依旧尝试写入
咱们来重现下sigpipe
这次执行命令需要考验手速了, 因为我们要赶在py醒过来之前, 将读端进程杀掉
输出结果
从上图我们可以验证两个点:
当我们杀掉读端时, 写端会收到sigpipe而默认退出, 管道结束
当我们杀掉读端时, 写端的程序并不会马上收到sigpipe, 相反的, 只有真正写入管道写端时才会触发这个错误
如果写入一个 读端已经关闭的管道, 将会收到一个sigpipe, 那读一个写端已经关闭的管道又会这样呢?
在上面也已经证明了上文提到的读写规则:如果所有管道写端对应的文件描述符被关闭,将产生eof结束标志，read返回0, 程序退出
总结
通过上面的理论和实验, 我们知道在使用管道时, 两边命令的数据传输过程, 以及对管道读写规则有了初步的认识, 希望我们以后在工作时, 再接触管道时, 能够更加有把握的去利用这一强大的工具。
基于STM32F的电脑鼠控制系统设计
线束测试仪怎么选型号的（常见的线束测试仪故障）
iQOO新旗舰机曝光将搭载骁龙865平台并配备了LPDDR5内存
将 GaN 技术推向新的阶段
光电池用途及应用
你所不知道的linux匿名管道知识详解
浅谈螺杆式压缩机的工作过程及工作原理
DBSyncer支持多种数据源和预警功能
腾讯医疗人工智能与医疗科技发展论坛在深圳举行
英特尔推出AI平台Articul8，提供全栈GenAI软件平台
一些也许你不知道的TINA-TI 资源！(IV)
电源的整流滤波原理图详解（五种滤波整流电路）
SAMP流程生成准确的跟踪掩膜的技术解析
日本半导体公司旭化成就遭遇大火
三相异步电动机正反转电气控制线路
电位器质量判断
图解华为昇腾310的用途以及设计细节
普通键盘接口转PS 2键盘转接器
LG将重组手机部门,将研发重心集中在高端智能手机上
高通发布了新型处理器Snapdragon 678
不过这次咱们不来说这些用法, 而是来探讨一些更加有意思的, 那就是管道两边的数据流实时性和管道使用的小提示。
其实我们在利用管道的时候, 可能会不经意的去想, 我前一个命令的输出, 是全部处理完再通过管道传给第二个命令, 还是一边处理一边输出呢? 可能在大家是试验中或者工作经验中, 应该是左边的命令全部处理完再一次性交给右边的命令进行处理, 不光是大家, 我在最初接触管道时, 也曾有这么一个误会, 因为我们通过现象看到的就是这样。
但其实只要有简单了解过管道这工具, 应该都不难得出解释:
管道是两边是同时进行, 也就是说, 左边的命令输出到管道, 管道的右边将马上进行处理。
管道的定义
管道是由内核管理的一个缓冲区，相当于我们放入内存中的一个纸条。管道的一端连接一个进程的输出。这个进程会向管道中放入信息。管道的另一端连接一个进程的输入，这个进程取出被放入管道的信息。一个缓冲区不需要很大，它被设计成为环形的数据结构，以便管道可以被循环利用。当管道中没有信息的话，从管道中读取的进程会等待，直到另一端的进程放入信息。当管道被放满信息的时候，尝试放入信息的进程会堵塞，直到另一端的进程取出信息。当两个进程都终结的时候，管道也自动消失。
管道工作流程图
通过上面的解释可以看到, 假设 command1 | command2, 那么command1的标准输出, 将会被绑定到管道的写端, 而command2的标准输入将会绑定到管道的读端, 所以当command1一有输出, 将会马上通过管道传给command2, 我们先来做个实验验证下:
在上面的命令, 我们可以猜测下输出结果: 究竟是 睡眠6秒之后, 输出1111222, 还是输出 1111 睡眠3秒, 再输出 2222, 然后再睡眠3秒, 再输出1111 呢? 答案就是: 都不是! what! 这不可能, 大家可以尝试下, 我们会看到终端没反应了, 为什么呢? 这就要涉及到文件io的缓冲方式了，这里不多说, 简单提一下文件io的三种缓冲方式:
全缓冲:直到缓冲区被填满，才调用系统i/o函数, (一般是针对文件)
行缓冲: 遇到换行符就输出(标准输出)
无缓冲:没有缓冲区，数据会立即读入或者输出到外存文件和设备上(标准错误
因为python是默认采用带缓冲的fputs,又因为标准输出被改写到管道, 所以将会采取全缓冲的方式(shell 命令具体要看实现, 因为有些是用不带缓冲write实现,如果不带缓冲区,会直接写入管道), 所以将会采取全缓冲的方式, 也就是说, 直到缓冲区被填满, 或者手动显示调用flush刷入,才能看到输出。那我们可以将代码改写成下面两种方式吧
输出结果:
在这里我们已经能够得出结果, 如果像我们以前所想的那样, 要等到command1全部执行完才一次性输出给command2, 那么结果应该是无限堵塞。因为我的程序一直没有执行完。这样应该是不符合老前辈们设计初衷的, 因为这样可能会导致管道越来越大。然而管道也是有大小的~ 具体可以去看posix标准, 所以我们得出结论是: 只要command1的输出写入管道的写端(不管是缓冲区满还是手动flush), command2都将立刻得到数据并且马上处理。
那么管道两边的数据流实时性讨论到就先暂告一段落, 接下来将在这个基础上继续讨论:管道使用的小提示。
在开始讨论前, 我想先引入一个专业术语, 也是我们偶尔会遇到的, 那就是:sigpipe。
或者是一个更加具体的描述:broken pipe(管道破裂)
上面的专业术语都是跟管道读写规则息息相关的, 那咱们来看下 管道的读写规则吧:
1.当没有数据可读时
o_nonblock (未设置)：read调用阻塞，即进程暂停执行，一直等到有数据来到为止。
o_nonblock ( 设置 ) ：read调用返回-1，errno值为eagain。
2.当管道满的时候
o_nonblock (未设置)： write调用阻塞，直到有进程读走数据
o_nonblock ( 设置 )：调用返回-1，errno值为eagain
3.如果所有管道写端对应的文件描述符被关闭，则read返回0
4.如果所有管道读端对应的文件描述符被关闭，则write操作会产生信号sigpipe
5.当要写入的数据量不大于pipe_buf时，linux将保证写入的原子性。
6.当要写入的数据量大于pipe_buf时，linux将不再保证写入的原子性。
在上面我们可以看到, 如果我们收到sigpipe信号, 那么一般情况就是读端被关闭, 但是写端却依旧尝试写入
咱们来重现下sigpipe
这次执行命令需要考验手速了, 因为我们要赶在py醒过来之前, 将读端进程杀掉
输出结果
从上图我们可以验证两个点:
当我们杀掉读端时, 写端会收到sigpipe而默认退出, 管道结束
当我们杀掉读端时, 写端的程序并不会马上收到sigpipe, 相反的, 只有真正写入管道写端时才会触发这个错误
如果写入一个 读端已经关闭的管道, 将会收到一个sigpipe, 那读一个写端已经关闭的管道又会这样呢?
在上面也已经证明了上文提到的读写规则:如果所有管道写端对应的文件描述符被关闭,将产生eof结束标志，read返回0, 程序退出
总结
通过上面的理论和实验, 我们知道在使用管道时, 两边命令的数据传输过程, 以及对管道读写规则有了初步的认识, 希望我们以后在工作时, 再接触管道时, 能够更加有把握的去利用这一强大的工具。
基于STM32F的电脑鼠控制系统设计
线束测试仪怎么选型号的（常见的线束测试仪故障）
iQOO新旗舰机曝光将搭载骁龙865平台并配备了LPDDR5内存
将 GaN 技术推向新的阶段
光电池用途及应用
你所不知道的linux匿名管道知识详解
浅谈螺杆式压缩机的工作过程及工作原理
DBSyncer支持多种数据源和预警功能
腾讯医疗人工智能与医疗科技发展论坛在深圳举行
英特尔推出AI平台Articul8，提供全栈GenAI软件平台
一些也许你不知道的TINA-TI 资源！(IV)
电源的整流滤波原理图详解（五种滤波整流电路）
SAMP流程生成准确的跟踪掩膜的技术解析
日本半导体公司旭化成就遭遇大火
三相异步电动机正反转电气控制线路
电位器质量判断
图解华为昇腾310的用途以及设计细节
普通键盘接口转PS 2键盘转接器
LG将重组手机部门,将研发重心集中在高端智能手机上
高通发布了新型处理器Snapdragon 678