What about something like:
type TimedReader interface {
TimedRead(out []byte,timeout int) (int,error)
}
so r.TimedRead(buf,0) becomes a non-blocking read?
On Thu, Mar 15, 2018 at 11:23 AM, Michael Jones <michael.jo...@gmail.com> wrote:
> What about: "wait, then get a buffer from a pool, and return. client uses
> buffer, then restores it." The present API could be used if the input buffer
> was presumed to go directly to that pool if not null, or, if a null pool
> argument means what i suggest and a new
> ReadWithReturnedBufferToSubmitToYourSecretPool() entry point.
>
> On Thu, Mar 15, 2018 at 10:04 AM, Ian Lance Taylor <i...@golang.org> wrote:
>>
>> 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.
>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> 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.
--
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.
