3 ms·
There is a race condition, or at least an avenue for a race condition, in this design. Even if myIO.ReadReady is unbuffered, there is nothing to stop another go
by sleepydog 10y ago
There is a race condition, or at least an avenue for a race condition, in this design. Even if myIO.ReadReady is unbuffered, there is nothing to stop another goroutine from calling myIO.ReadReady after the select case is entered. The channel receive would have to return an exclusive handle of some type that could used to read from myIO. And then at that point, how do you signal to myIO that you are done reading? Should myIO "unlock" after a single Read call? After all pending data has been consumed? What if you're using a parsing package that calls Read multiple times? How do you keep it from blocking?
- zimbatm 10y agoUsually IO read (or writes) should only be handled by a single goroutine at the same time. I don't think that the Read() function provides concurrent access guarantees either. But you're right that myIO.ReadReady doesn't give the guarantee that there is enough data to fill the len(buf) on the next Read call, which would make it then blocking.