You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 21, 2023. It is now read-only.
The remove call fails to remove the entry, as an other thread is editing the toEvict entry. Shouldn't we check if the remove worked, and for example silently return if it did not ?
The text was updated successfully, but these errors were encountered:
It's close to what we want. I think it's going to run faster as a single loop that runs until the size is sufficiently small, or there's nothing left to remove. (Since we only allocate one iterator). Even better if you can fast-fail at the front and avoid allocating the iterator at all if the cache is already sufficiently small.
And even better, send the pull request against OkHttp? Its DiskLruCache is developed further than this one. Someday we should just simplify this project into a repackaging of a subset of that code.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello guys,
I use DiskLruCache in a multi-thread environment. I get an infinite loop in the trimToSize method:
while (size > maxSize) {
Map.Entry<String, Entry> toEvict = lruEntries.entrySet().iterator().next();
remove(toEvict.getKey());
}
The remove call fails to remove the entry, as an other thread is editing the toEvict entry. Shouldn't we check if the remove worked, and for example silently return if it did not ?
The text was updated successfully, but these errors were encountered: