On Thursday, March 15, 2018 at 3:37:51 AM UTC+8, Ian Lance Taylor wrote:
>
>
> Even for TCP, that's an interesting point. I wonder if we should have
> a way to specify a number of bytes to read such that we only allocate
> the []byte when there is something to read.
>
I was thinking a better approach is to split I/O readiness and actual I/O
operations. Currently we combine the two in one step, e.g.
r.Read(buf) // blocks until r is readable, and then copy into buf
What if we could instead do
for ok := runtime.WaitRead(r, timeout); ok {
buf := bufPool.Get().([]byte) // get a buffer from a sync.Pool
r.Read(buf) // should not block here because r is readable
process(buf) // perform application-specific actions on the read
data
bufPool.Put(buf) // return the buffer to sync.Pool so it could be
reused by other goroutines blocked in similar manner
}
The additional runtime.WaitRead function should be a rather simple change
to expose the internal poller signal. In this model, the buffer is only
needed when the read-ready signal comes.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
