On Thu, Mar 15, 2018 at 12:04 PM, Rio <m...@riobard.com> wrote: > > On Friday, March 16, 2018 at 1:05:12 AM UTC+8, Ian Lance Taylor wrote: >> >> >> 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. > > > I might not understand the racy part completely. Could you please explain a > bit more what would be wrong if multiple goroutines read from the same > Reader? Is it when multiple goroutines will be woken up by WaitRead but then > we don't know which one will actually Read?
Multiple goroutines will be woken up by WaitRead, they will all call Read, only one of those Reads will succeed, the others will block. For your case it may not matter but if there is other work for the goroutine to do, the goroutine may expect that because WaitRead succeeded, Read will not block, but that is not guaranteed. In effect WaitRead is a trap: it means that Read may or may not block. > An alternative solution without introducing any new API could be that we > somehow specify the behavior of Read(buf) when len(buf) == 0, so multiple > goroutines can just do > > r.Read(nil) // all goroutine blocked here till r is readable > buf := bufPool.Get().([]byte) // get buf from sync.Pool > r.Read(buf) // actual read here > process(buf) > bufPool.Put(buf) // return buf to pool > > This style should in theory avoid the racy question, right? Still seems racy to me. You may want to look at https://github.com/golang/go/issues/15735#issuecomment-266574151 . 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.
