Hacker News Reader

Comment by kornish | Hacker News Reader

Instead of supplying a buffer to each read call itself, you can use something like a sync.Pool which will give metered and concurrency-safe access to a buffer: https://golang.org/pkg/sync/#Pool.

View on HN

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.

Yep, 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."

Exactly. The sync.Pool will only be useful if net.Conn.Read accepted a Writer instead of []byte.

That wouldn't make much sense since the Reader interface requires []byte, but the specific connection could inherit WriterTo: https://golang.org/pkg/io/#WriterTo

(TCPConn implements ReaderFrom, but not WriterTo)

I 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.

> 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.

Ah right.

Reply on news.ycombinator.com