if @block
rd, wr = IO.pipe
@pid = fork do
$0 = "Forked child from Page #{@path}"
rd.close
result = @block.call(@resp.body)
begin
wr.write Marshal.dump(result)
end
wr.close
这是与 fork 共享管道的非常标准的方法,但是一旦 rd.close
被调用,它就会断开管道供 wr
使用。直到那条线,管道才能正常工作(我用 Pry 逐行运行它)。据我所知,关闭 fork 内的读取器以阻止它干扰发送 EOF 是一种很好的做法(我不知道为什么会这样,我只知道这是做法)。
这是我调用到生产应用程序中的库的一部分。图书馆自己的规范从来没有遇到过这种情况,即使它们运行非常相似的代码(只有 @block
和 @resp
会有很大的不同)。显然应用程序的代码更复杂,但我看不出它会如何干扰这段代码。我搜索了该应用程序所需的其他库,以查看是否有任何可能干扰此的捕获信号,但我一无所获。
谁能提出问题所在或解决方法?我已经 try catch Errno::EPIPE
异常和 retry
ing 但这并没有解决它,重新打开管道(我不完全确定该怎么做无论如何,在 fork 发生后很难将它链接到主进程),清空 block 所以它不做任何工作......仍然没有快乐。
我还发现(通过对 this question 的评论)标准库中的 Ruby 的 Open3 默默地挽救并删除了 Errno::EPIPE
但提交消息中没有给出任何原因。不知道有没有关系。
https://github.com/ruby/ruby/blob/e3c288569833b6777e7ecc0bbc26f8e6ca8f2ba7/lib/open3.rb#L268
最佳答案
不知道为什么花了这么长时间才得到答复。我怀疑这在当前版本的 ruby 中是“固定的”,因为我无法使用您代码的简化版本进行复制,但为了将来引用,以下是我构建代码的方式:
def test_my_pipes
rd, wr = IO.pipe
fork do
rd.close
sleep 5
wr.write "Hello world"
wr.close
end
wr.close # essential
puts "Waiting for sleepy fork"
puts rd.read
rd.close
end
请注意,在 fork block 的内部和外部,我们都关闭了 rd 和 wr。实际上,只有父进程wr.close
是必需的,但最好在不需要时关闭所有管道末端。
如果此代码仍然无法正常运行,我们将有兴趣查看他们为哪些版本的 ruby 崩溃。
关于ruby - Errno::EPIPE:引发破损管道异常,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44617151/