如何避免并行命名管道的死锁？

Question

我正在开发一个基于流的编程系统net2sh 。 它当前基于通过命名管道连接的Shell工具。 多个过程协同工作以完成工作，并通过命名管道进行通信，这与工厂的生产线不同。

总的来说，它运行良好，但是存在一个主要问题。 在进程通过两个或多个命名管道进行通信的情况下，“发送”过程和“接收”过程必须以相同的顺序打开管道。 这是因为当进程打开命名管道时，它将阻塞直到另一端也被打开为止。

我想要一种避免这种情况的方法，而不必为每个管道产生额外的“帮助程序”进程，而不必破解现有组件，也不必弄乱程序网络来避免此问题。

理想情况下，我正在寻找一些“ non-blocking fifo”选项，其中fifo上的“ open”总是立即成功执行，但是如果管道缓冲区已满（或为空，以便读取），后续操作可能会阻塞...我什至会考虑使用内核补丁来达到这一目的。 根据fifo（7），O_NONBLOCK在打开fifos时会做一些不同的事情，不是我想要的，要使用它，我必须重写所有现有的shell工具（例如cat）。

这是一个死锁的最小示例：

mkfifo a b
(> a; > b; ) &
(< b; < a; ) &
wait

如果您能帮助我明智地解决此问题，我将不胜感激！

Answer 1

此处对将O_NONBLOCK与命名管道一起使用有很好的描述： 如何在命名管道（mkfifo）上执行非阻塞fopen？

听起来好像您希望它在整个环境中都能工作而不更改任何C代码。 因此，一种方法是将LD_PRELOAD设置为某个共享库，该共享库包含open(2)的包装器，每当pathname引用命名管道时，该包装器就会在flags添加O_NONBLOCK 。

一个使用LD_PRELOAD重写库函数的简洁示例在这里： https : //www.technovelty.org/c/using-ld_preload-to-override-a-function.html

无论这实际上是否在实践中起作用而没有破坏其他任何内容，您都必须自己弄清楚（请告诉我们！）。