On Thu, Mar 15, 2018 at 8:58 AM, Rio <m...@riobard.com> wrote:
>
> 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.
That's inherently racy, though. It's quite normal to have multiple
goroutines reading from the same socket. That is awkward if we split
up WaitRead and Read. Better to have a single wait-then-read
operation, as we do today.
Ian
--
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
