Revert cache FIFO replacement policy to reset/clear #134
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.
Amongst other changes, #113 switched the cache to a FIFO inspired by
the standard library's re module, however it didn't really take
concurrency in account, so didn't really consider: that double-pops
are possible (probably why the stdlib ignores a bunch of errors),
which can cause KeyError during lookup (as two workers try to clear
the first key, one succeeds, and the other doesn't find the key and
fails).
It also has a few other less major issues:
capacity permanently by the number of concurrent workers
ordered
dict, but I'd rather not drop 2.7 compatibility from 0.xunless there are very good causes to as, despite 2.7 having been
EOL'd in 2020, it still accounts for more downloads than 3.10
(according to pypistats)
Using an ordered dict would solve (3), and allow using an LRU rather
than a FIFO, but it would not actually prevent double-pops or
double-inserts, that would require a proper lock on lookup. Which
might not be that expensive but given the lack of a good dataset to
bench with, it seems a lot of additional complexity for something
we've got no visibility on. But that can be considered if someone
reports a serious performance regression from this.
So for now just revert to a "reset" cache replacement policy. If /
when we drop older versions we can switch to
functools.lru_cacheandlet the stdlib take care of this (and possibly have cache
stats). Alternatively if we get a good testing dataset one day we can
bench cache replacement policies or even provide pluggable policies.
Anyway fixes #132, closes #133