由于Go语言具有通道,我想知道为什么标准库似乎没有被设计成也使用它们进行IO。
相反,有读取器和写入器类型,但是使用通道会有什么问题呢?
一个函数可以返回一个字节片段的通道(假设单个字节或甚至单个位的返回太低效了),并接收一个用于取消请求的通道和一个用于错误报告的通道。
-好奇的Go新手。
由于Go语言具有通道,我想知道为什么标准库似乎没有被设计成也使用它们进行IO。
相反,有读取器和写入器类型,但是使用通道会有什么问题呢?
一个函数可以返回一个字节片段的通道(假设单个字节或甚至单个位的返回太低效了),并接收一个用于取消请求的通道和一个用于错误报告的通道。
-好奇的Go新手。
通道是在 goroutine 之间进行通信的好方法。当程序执行简单操作,例如读取 stdin,对流进行处理并将结果输出到 stdout 时,使用通道会过度设计,不必要地影响性能。
只要标准库没有在某个地方提供特定于 goroutine 之间通信的功能,就没有理由使用通道来模拟像 io.Reader
或 io.Writer
这样简单的操作,或者具有基于通道的方法集(API)。
此外,在需要的情况下,可以将简单实现包装在通道中,而相反地,“解包”通道实现回到其原始状态是不可能的。此外,Go 作者显然喜欢明确性,这导致性能瓶颈不被隐藏(并且令人惊讶)。
io.Reader
和io.Writer
存在的另一个原因是它们在单线程级别上表现良好;通道几乎专门用于协程间通信或多线程模型。虽然有些情况下可以互换使用,但它们的设计目的是解决两个不同的挑战。
io.Reader
和io.Writer
还具有EOF的概念,这很难通过通道轻松复制,除非您在通道上叠加一个单独的协议-这当然只会增加负担。
P.S.关闭通道与EOF也不同,因为关闭通道会防止将来使用它。我的这个包将io.Reader和io.Writer封装成一个通道。
换句话说,它创建了一个线程安全的缓冲区。
换句话说,它是一个通用的管道。