- Add support for some 32-bit platforms where
std::sync::atomic::AtomicU64
is not provided. (e.g.armv5te-unknown-linux-musleabi
ormips-unknown-linux-musl
)- On these platforms, you will need to disable the default features of Moka. See the relevant section of the README.
- Fix a bug in
get_or_insert_with
andget_or_try_insert_with
methods offuture::Cache
by adding missing boundsSend
and'static
to theinit
future. Without this fix, these methods will accept non-Send
or non-'static
future and may cause undefined behavior. (#31) - Fix
usize
overflow on big cache capacity. (#28)
- Add examples for
get_or_insert_with
andget_or_try_insert_with
methods to the docs. (#30)
- Downgrade crossbeam-epoch used in moka-cht from v0.9.x to v0.8.x as a possible workaround for segmentation faults on many-core CPU machines. (#33)
- Replace a dependency cht v0.4 with moka-cht v0.5. (#22)
- Add
get_or_insert_with
andget_or_try_insert_with
methods tosync
andfuture
caches. (#20)
- Breaking change: Now
sync::{Cache, SegmentedCache}
andfuture::Cache
requireSend
,Sync
and'static
for the generic parametersK
(key),V
(value) andS
(hasher state). This is necessary to prevent potential undefined behaviors in applications using single-threaded async runtime such as Actix-rt. (#19)
- Add
invalidate_entries_if
method tosync
,future
andunsync
caches. (#12)
- Stop skeptic from having to be compiled by all downstream users. (#16)
- Add an unsync cache (
moka::unsync::Cache
) and its builder for single-thread applications. (#9) - Add
invalidate_all
method tosync
,future
andunsync
caches. (#11)
- Fix problems including segfault caused by race conditions between the sync/eviction thread and client writes. (Addressed as a part of #11).
- Add an asynchronous, futures aware cache (
moka::future::Cache
) and its builder. (#7)
- Add thread-safe, highly concurrent in-memory cache implementations
(
moka::sync::{Cache, SegmentedCache}
) with the following features:- Bounded by the maximum number of elements.
- Maintains good hit rate by using entry replacement algorithms inspired by
Caffeine:
- Admission to a cache is controlled by the Least Frequently Used (LFU) policy.
- Eviction from a cache is controlled by the Least Recently Used (LRU) policy.
- Expiration policies:
- Time to live
- Time to idle