IO通道与读/写器

Question

由于Go有频道，我想知道为什么标准库似乎没有被设计为将它们用于IO。

有相反的读者和作者类型，但使用频道会出现什么问题？

函数可以返回字节片的通道（假设单字节，甚至单位返回效率太低），并为取消请求和错误报告通道接收通道。

- 好奇的Go新手。

Answer 1

频道非常适合在goroutines之间进行通信。当程序执行简单的操作时，例如读取stdin，使用流做某事并将结果输出到stdout - 然后使用通道是一种过度杀伤，不必要地损害性能。

只要标准库在某些地方没有提供特定于goroutines相互通信的内容，就没有充分的理由来建模简单的操作，例如io.Reader或io.Writer使用频道的操作，分别具有基于通道的方法集（API）。

此外，在需要时，简单的实现可以包含在一个通道中，而相反，将一个通道实现“解包”回其原语是不可能的。此外，Go作者显然喜欢露骨，导致性能瓶颈不被隐藏（并且令人惊讶）。

Answer 2

我的这个包实现了将 io.Reader 和 io.Writer 封装到一个通道中。

或者，换句话说，它创建了一个线程安全的缓冲区。

或者，换句话说，它是一个通用管道。

https://github.com/latitov/milkthisbuffer

Answer 3

我认为存在io.Reader和io.Writer的另一个原因是因为它们在单线程级别上发挥出色；通道几乎专门用于goroutine通信或多线程模型。在某些情况下，您可以互换使用它们，但是它们旨在解决2个不同的挑战。 io.Reader和io.Writer也具有EOF的概念，除非您在通道上分层放置单独的协议，否则EOF不能轻易地通过通道进行复制-这当然是一个过大的选择。 附言关闭通道与EOF都不相同，因为关闭通道会阻止将来使用它。