Closed puellanivis closed 4 years ago
No, I don’t think so. There’s a bit of a hope to avoid touching as much as possible, so as little can break as possible. 😆
I just did a quick test and it seems fine for me, all my test cases passed and also manual checking for transfer errors seems ok, thanks!
:grumble-grumble: merge conflicts when a delete and a delete/insert end up head-to-tail next to each other.
@eikenb this seems now good to go. Wanna merge it?
I’m usually hesitant to commit my own merges if there are no other checks on code. But sure, I think everyone is pretty satisfied that this won’t shouldn’t massively break anything.
So, I end up moving the “tautological statement” into a function under
Request
(transferError(err error)
). The new function better encapsulates behavior of theRequest
object to calls on theRequest
object. So, while the check now still exists, it at least is an appropriate guard statement, guarding against potential misbehavior.The thing I noticed during PR-361, is that the
break
in theswitch { default: … }
does not break out of thefor { … }
loop, but rather only out of theswitch
. Meaning, thebreak
as it originally appeared was actually a no-op, and execution wasn’t properly ending in that situation.The solution was to move the
for { … }
loop into its own independent function, where the loop can then be broken clearly and unambiguously with areturn
.Additionally, I noticed that although we’re looping over
openRequests
, which is supposed to only be accessed under lock, we were not actually holding the lock at that point.As well,
Request.Close
really should be closing both thereaderAt
and thewriterAt
if they implement,io.Closer
, even if the first one returns anerr != nil
error.