命名管道：一些实验导致混乱

Question 1

要按编号回答您的问题列表：

命名管道，又名 fifo，本质上等同于 shell 生成的无名管道。最大的区别在于，对于 shell 版本来说，两端之间的同步是直观的，而您似乎使用的命名管道需要一些有关 shell 为您做什么的知识。
是的，两端都在等待对方。 fifo 的用途与 shell 管道一样，是将一个进程的输出传递到另一个进程的输入。他们是不是临时文件。我怀疑这就是你感到困惑的地方。对于像这样的 shell 命令cat somefile.txt | less，两个都命令作为分叉进程同时运行，管道用于同步这两个进程。如果没记错的话，可以在 C 语言中修改它，但使用 shell 命令就不那么容易了。
当管道的另一端获得连接时，进程可以接收信号，但如上所述，整个意图通常是保持两个进程同步。写入器发送一些内容，并且它知道写入操作完成后可以继续。
bash并且tcsh不会让你“遗忘”。该命令甚至没有运行。
tail -f必须读取整个流，直到获得 EOF（在本例中为）stdin，然后才能显示任何内容。在你的实验中，结局从未出现。cat另一方面，可以立即开始处理其输入。
由于写入过程不会发送任何换行符，因此读者只需阅读，直到被告知“足够了”。在第一种情况下，可能是因为 fifo 的缓冲区已满，因此被刷新到读取器。随后的输出可能类似，并且可能会根据系统时序而有所不同。

让我在这里解决另一个令人困惑的问题。 shell 处理重定向前运行命令。这意味着您不会cat在进程列表中看到，因为bash卡住了等待 fifo 的另一端连接前跑步cat或任何涉及作家的事情。同样，在连接写入器之前它不会执行读取命令。

我认为你在这里最大的误解是命名管道是不是临时文件。两者都不是无名管道。虽然有多种方法可以使通信异步，但看起来您最好在下创建实际的临时文件/tmp，除非您做希望两个进程同时运行。

Answer

要按编号回答您的问题列表：

命名管道，又名 fifo，本质上等同于 shell 生成的无名管道。最大的区别在于，对于 shell 版本来说，两端之间的同步是直观的，而您似乎使用的命名管道需要一些有关 shell 为您做什么的知识。
是的，两端都在等待对方。 fifo 的用途与 shell 管道一样，是将一个进程的输出传递到另一个进程的输入。他们是不是临时文件。我怀疑这就是你感到困惑的地方。对于像这样的 shell 命令cat somefile.txt | less，两个都命令作为分叉进程同时运行，管道用于同步这两个进程。如果没记错的话，可以在 C 语言中修改它，但使用 shell 命令就不那么容易了。
当管道的另一端获得连接时，进程可以接收信号，但如上所述，整个意图通常是保持两个进程同步。写入器发送一些内容，并且它知道写入操作完成后可以继续。
bash并且tcsh不会让你“遗忘”。该命令甚至没有运行。
tail -f必须读取整个流，直到获得 EOF（在本例中为）stdin，然后才能显示任何内容。在你的实验中，结局从未出现。cat另一方面，可以立即开始处理其输入。
由于写入过程不会发送任何换行符，因此读者只需阅读，直到被告知“足够了”。在第一种情况下，可能是因为 fifo 的缓冲区已满，因此被刷新到读取器。随后的输出可能类似，并且可能会根据系统时序而有所不同。

让我在这里解决另一个令人困惑的问题。 shell 处理重定向前运行命令。这意味着您不会cat在进程列表中看到，因为bash卡住了等待 fifo 的另一端连接前跑步cat或任何涉及作家的事情。同样，在连接写入器之前它不会执行读取命令。

我认为你在这里最大的误解是命名管道是不是临时文件。两者都不是无名管道。虽然有多种方法可以使通信异步，但看起来您最好在下创建实际的临时文件/tmp，除非您做希望两个进程同时运行。

Question 2

find | less

当我点击shift+g（转到文件末尾less）时，硬盘立即开始工作并开始输出数据。这是否意味着当less命令有足够的数据来显示时，它会以某种方式告诉find不要生成更多数据？

不可以。管道适用于read()s 和write()s。less告诉find 没有什么- 但是只要有一个read()与之关联的进程，拥有该管道的系统内核就不会刷新它。如此find write()直到它不能write()再继续，因为管道缓冲区已满并且内核不接受另一个缓冲区write()。find也是如此堵塞编辑。当您跳到管道输入的末端时，less read()管道会排出一些 -（全部）- 该管道缓冲区find现在可以write()再次使用 - 确实如此。它恢复对磁盘的搜索，并尝试再次填充该缓冲区或完成其工作。

同样的道理命名管道- 这是完全相同的事情 - 除了内核同意将管道的两端与伪文件关联 - a关联- 文件系统中的某处。当你：

mkfifo pipe
echo > pipe &
rm pipe
mkfifo pipe
cat pipe

...您正在与两个不同的管道。第一个与unlink()ed by的文件系统名称相关联rm- 但echo仍在其管道上等待read()er - 尽管现在任何进程都不太可能找到另一端。事实上，您基本上可以通过这种方式使命名管道匿名，同时仍然使用它 - 出于安全原因，这通常是最佳实践。

尝试：

   mkfifo pipe
   exec 3<>pipe 4<>pipe
   cat  <&3     >out.log &
   rm pipe
   echo read this, cat\! >&4

Answer

find | less

当我点击shift+g（转到文件末尾less）时，硬盘立即开始工作并开始输出数据。这是否意味着当less命令有足够的数据来显示时，它会以某种方式告诉find不要生成更多数据？

不可以。管道适用于read()s 和write()s。less告诉find 没有什么- 但是只要有一个read()与之关联的进程，拥有该管道的系统内核就不会刷新它。如此find write()直到它不能write()再继续，因为管道缓冲区已满并且内核不接受另一个缓冲区write()。find也是如此堵塞编辑。当您跳到管道输入的末端时，less read()管道会排出一些 -（全部）- 该管道缓冲区find现在可以write()再次使用 - 确实如此。它恢复对磁盘的搜索，并尝试再次填充该缓冲区或完成其工作。

同样的道理命名管道- 这是完全相同的事情 - 除了内核同意将管道的两端与伪文件关联 - a关联- 文件系统中的某处。当你：

mkfifo pipe
echo > pipe &
rm pipe
mkfifo pipe
cat pipe

...您正在与两个不同的管道。第一个与unlink()ed by的文件系统名称相关联rm- 但echo仍在其管道上等待read()er - 尽管现在任何进程都不太可能找到另一端。事实上，您基本上可以通过这种方式使命名管道匿名，同时仍然使用它 - 出于安全原因，这通常是最佳实践。

尝试：

   mkfifo pipe
   exec 3<>pipe 4<>pipe
   cat  <&3     >out.log &
   rm pipe
   echo read this, cat\! >&4

命名管道：一些实验导致混乱

答案1

答案2

相关内容