Go管道写端被关闭，为什么？

Golang小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《Go管道写端被关闭，为什么？》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

我刚刚读了一些 go 代码，它执行以下操作：

some_binary 是一个长时间运行的进程。

1. 为什么 inst.wpipe 关闭并设置为 nil？如果不关闭的话会发生什么？关闭 inst.wpipe 是否常见/有必要？
2. dup2(pipe_fd[1], 1) 是 cmd.stdout = inst.wpipe; 的 c 类似物吗？ inst.wpipe.close()?

正确答案

该代码是典型的想要读取其他程序生成的输出的程序。 os.Pipe() 函数返回一对连接的 os.file 实体（或者，发生错误时，不应简单地忽略该实体），其中第二个（w 或 wpipe）实体上的写入在第一个实体上显示为可读字节（ r / rpipe) 实体。但是——这是第一个问题答案的一半关键——读者如何知道所有作者何时完成写作？

为了让读取器获得 eof 指示，所有拥有或有权访问管道写入端的写入器必须调用 close 操作。通过将管道的写入端传递给我们以 cmd.start() 启动的程序，我们允许该命令访问管道的写入端。当该命令关闭该管道时，具有访问权限的实体之一已关闭该管道。但另一个具有访问权限的实体尚未关闭它：我们拥有写入权限。

要查看 eof，我们必须使用 wpipe.close() 关闭对我们的 wpipe 的访问。所以回答前半部分：

1. 为什么 inst.wpipe 关闭并设置为 nil？

set-to-nil 部分可能有也可能没有任何功能；您应该检查其余的代码以确定它是否有效。

1. dup2(pipe_fd[1], 1) 是 cmd.stdout = inst.wpipe; 的 c 类似物吗？ inst.wpipe.close()?

不完全是。 dup2 级别在 posix os 区域中较低，而 cmd.stdout 处于较高（与操作系统无关）级别。 cmd.start() 的 posix 实现将在调用 fork （或等效的东西）之后最终调用 dup2 （或等效的东西）。 inst.wipe.close() 的 posix 等效项是 close(wfd)，其中 wfd 是 wpipe 中的 posix 文件编号。

在没有任何更高级别包装的 c 代码中，我们会有类似的内容：

（尽管如果我们足够仔细地检查 close 中的错误，我们可能应该足够仔细地检查 pipe 系统调用是否给我们返回了描述符 0 和 1，或者 1 和 2，或者 2 和 3，在这里，也许我们可以通过确保 0、1 和 2 至少对 /dev/null 开放来更早地处理这个问题。

理论要掌握，实操不能落！以上关于《Go管道写端被关闭，为什么？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！