Locking check interval #334
Merged
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.
Adds a
check_intervaloption to the@cache.lockeddecorator, which controls how long the backend will wait in between attempts to set the lock while another task has acquired the lock.This helps avoid hitting the backend many times in a short timespan when concurrent async tasks or processes are trying to run the same locked function.
The default behavior of the lib is unchanged as the default value of
check_interval=0, so it still doesawait asyncio.sleep(0)to just proceed to the next task on the event loop without wait when the argument is not specified.More context in #333. This gives a "good enough" solution for my use case for now but we may consider using a pub/sub approach in the future for backends that could support it (Redis).
Also a couple small test updates (let me know if you want me to separate these out):
protected=Falseto the@cache(lock=True)test as whenprotected=Truethe test passes without even passinglock=True.