Closed cdonati closed 6 years ago
I didn't notice the previous pull request until I was submitting this one, so I added the last commit to address the concern about 0
being passed to socket.settimeout
.
@StephenSorriaux Your suggestion about just passing timeout
along makes sense. The socket timeout should probably not be influenced by the amount it takes to establish the connection. However, in the interest of keeping the changes here to a minimum, I'll let a different pull request address that behavior.
@StephenSorriaux Thanks for the review. Originally, I wasn't sure if (core) was applicable here for the scope, but that makes sense now.
In addition to the tests you suggested, I also added a couple tests for nonpositive timeout values.
Let me know if the amended commits address all of your comments.
@StephenSorriaux Your changes look good to me. Would you prefer I use the "Apply suggestion" feature on all of them or should I push the changes you suggested as a single additional commit?
@cdonati I think it is better that you push the changes, I'm not sure how many commits will be created using the "Apply suggestion" feature. Just keep only 1 commit on your branch and it would be perfect.
@StephenSorriaux I just saw your comment about a single commit. I squashed the commits accordingly.
@cdonati Thanks again for your PR, I'm merging it to master.
Previously, a gap between calls to
time.time()
could lead to a situation where the current time was less thanend
during thewhile
condition, but it was greater thanend
when assigning a value totimeout_at
.This is the same issue describe in https://github.com/python-zk/kazoo/pull/518, but the fix is slightly different. It avoids a redundant call to
time.time()
. I've also included a unit test that exhibits the problem when run without the fix.