5 ms·
I think you misunderstand. It's not that you can't get a pooled buffer in Go. The problem is that you don't know if/when you need that buffer without calling Re
by kevinherron 10y ago
I think you misunderstand. It's not that you can't get a pooled buffer in Go. The problem is that you don't know if/when you need that buffer without calling Read(), and the call to Read() requires a buffer that's ready to use.
- kornish 10y agoYep, you're totally right. Reread a couple times and the crux of the matter seems to lie here: "Unlike with C, in Go there is no way to know if a connection is readable, other than to actually try to read data from it."
- vendakka 10y agoExactly. The sync.Pool will only be useful if net.Conn.Read accepted a Writer instead of []byte.
- deleted 10y ago[deleted]
- masklinn 10y agoThat wouldn't make much sense since the Reader interface requires []byte, but the specific connection could inherit WriterTo: https://golang.org/pkg/io/#WriterTo https://golang.org/pkg/io/#WriterTo (TCPConn implements ReaderFrom, but not WriterTo)
- vendakka 10y agoI wasn't very clear. A hypothetical conn.Read(w Writer) would call Write on w instead of filling a byte array. Write in turn allocates as needed. WriterTo is a cleaner way of doing this.
- masklinn 10y ago> A hypothetical conn.Read(w Writer) would call Write on w instead of filling a byte array. Yes I understand the purpose — hence suggesting WriterTo which is supposed to do that — I simply noted that conn.Read(w Writer) would make Conn not extend io.Reader anymore since it takes a buffer.
- vendakka 10y agoAh right.