由于 Go 有通道，我想知道为什么标准库似乎没有被设计为将它们用于 IO。
相反，有读者和作家类型，但使用渠道会有什么问题？
一个函数可以返回一个字节切片通道（假设单字节，甚至单比特返回效率太低），并接受一个用于取消请求的通道和一个用于错误报告的通道。
-好奇的围棋新手。
问问题
3543 次
3 回答
12
通道非常适合 goroutine 之间的通信。当一个程序做一些简单的事情时，例如读取标准输入，对流做一些事情并将结果输出到标准输出 - 然后使用通道是一种过度杀伤，不必要地损害性能。
只要标准库在某些地方没有提供特定于 goroutine 相互通信的东西，就没有充分的理由对简单的操作进行建模，例如使用通道io.Reader或io.Writer使用通道的操作，分别具有基于通道的方法集 (API)。
此外，在需要时，可以将简单实现包装在通道中，而相反，将通道实现“解包”回其原语是不可能的。此外，Go 作者显然喜欢明确性，导致性能瓶颈没有被隐藏（并且令人惊讶）。
于 2012-12-02T10:08:27.517 回答
1
我认为存在的另一个原因io.Reader是io.Writer因为它们在单线程级别上运行良好；通道几乎专门用于 goroutine 间通信或多线程模型。在某些情况下，您可以互换使用它们，但它们旨在解决 2 个不同的挑战。
io.Reader并且io.Writer还具有无法通过通道轻松复制的 EOF 概念，除非您在通道上分层一个单独的协议 - 这当然只是一种矫枉过正。PS 关闭通道与 EOF 也不一样，因为关闭通道会阻止它在将来被使用。
于 2020-05-02T07:25:56.843 回答
1
我的这个包实现了将 io.Reader 和 io.Writer 包装成一个通道。
或者，换句话说，它创建了一个线程安全的缓冲区。
或者，换句话说，它是一个通用管道。
于 2020-12-22T22:45:16.123 回答