Repository navigation
π fix(api): reject a non-bool blocking in acquire() - #870
Merged
Merged
Conversation
β¦ it as truthy The constructor and the ``blocking`` setter reject a value that is not a bool, but ``acquire()`` accepted one and fell back to truthiness. A configuration string such as ``"false"`` is truthy, so a call that asked for a single non-blocking attempt waited for the instance's ``timeout`` instead, and with the default ``timeout=-1`` that wait has no limit. ``acquire()`` now validates the argument the same way the constructor does, in both the sync and the async implementation, and raises the same ``TypeError``. Signed-off-by: simpleqt <2015900818@qq.com>
The constructor and the setter already share the validator, so the acquire() call sites need no comment restating that; one line on the sync path keeps the why. The tests that passed blocking=None are gone: test_singleton_handed_out_while_finalizing_keeps_its_hold and the async singleton test already drive acquire() through an instance built with blocking=False and expect Timeout, and an uncontended acquire passes whatever blocking resolves to. One string and one int per suite cover the rejected types.
gaborbernat
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A lock built with a configuration value such as
blocking="false"failed fast, because the constructor and theblockingsetter reject anything that is not abool.acquire(blocking=...)took the same string and read it as truthy, so a call meant as a single attempt waited for the instance'stimeout, without a limit at the default-1. The process hung where it should have raised.acquire()onFileLock,SoftFileLockand their async twins now runs the validator the constructor and setter already share, afterNonehas resolved to the instance's setting, so every entry point that takesblockingraises the sameTypeErrorfor a non-bool. π A call that passedblocking=1orblocking=0and relied on truthiness now raises; passTrueorFalse.