New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BF: do not use .acquired - just get state from acquire() #5718
Conversation
Somewhat ad-hoc and makes an already confusing lock_if_check_fails even more so by optionally changing its return signature. So eventually we might want to RF this whole piece of code. But I think it should work ok for now. Anyways -- fasteners 0.16.x series might re-gain .acquired (see harlowja/fasteners#71) and we might want to see to RF this PR properly if so instead of merging/releasing it right away. But FWIW Closes datalad#5717
Codecov Report
@@ Coverage Diff @@
## maint #5718 +/- ##
===========================================
- Coverage 90.28% 29.52% -60.77%
===========================================
Files 299 296 -3
Lines 42349 42316 -33
===========================================
- Hits 38234 12492 -25742
- Misses 4115 29824 +25709
Continue to review full report at Codecov.
|
Since it seems like fasteners will not only regain the attribute but actually remove the release from pypi, we might want to give them 24h or so, before reacting with a quick fix, I think (much longer doesn't really work with entire CI broken). |
0.16.2 is released, tested locally that our "locking" tests now back to normal. But I think we should still proceed with this PR, even if without major rush ;-) As mentioned in harlowja/fasteners#71 (comment) it is pretty much not advised to rely on it, and our code can be easily RFed as done here to not. It is only the tests are kinda troublesome and I forgot all this locking kitchen to possibly find a better way to fix up the tests without changing the API. |
Never really looked into it, but it seems to me, that the solution is not to not return |
IIRC I had considered that option too but for some reason decided to just return... Looking at the code: self._do_open()
watch = _utils.StopWatch(duration=timeout)
r = _utils.Retry(delay, max_delay,
sleep_func=self.sleep_func, watch=watch)
with watch:
gotten = r(self._try_acquire, blocking, watch)
if not gotten:
self.acquired = False
return False
else:
self.acquired = True
self.logger.log(_utils.BLATHER,
"Acquired file lock `%s` after waiting %0.3fs [%s"
" attempts were required]", self.path,
watch.elapsed(), r.attempts)
return True where |
Yeah. So - just store the return value of |
well, I already store it in a variable now in that function: https://github.com/datalad/datalad/pull/5718/files#diff-c4170b6a46f8d90d2bdcb206966fe9f16e8a431395245d39434edb681ab03ca6R94 . The question is how to channel back to the test on either lock was acquired or not (if not blocking). Having slept on it, I will just document that the |
Somewhat ad-hoc and makes an already confusing lock_if_check_fails even more so
by optionally changing its return signature. So eventually we might want
to RF this whole piece of code. But I think it should work ok for now.
Anyways -- fasteners 0.16.x series might re-gain .acquired (see
harlowja/fasteners#71) and we might want to see to RF
this PR properly if so instead of merging/releasing it right away. But FWIW
Closes #5717