If APCu is used to permanently store individual config values, then the current behavior of respecting the TTLs makes sense, for predictability
If APCu is used in front of redis/memcached or a fast enough database/service/etc, then users should have a way to indicate that it's fine to evict keys to make room for new keys (it may make sense to prefer evicting keys with an older last accessed time, fewer hits vs time unit, etc)
(Aside: Internally, memcached always allows for early eviction, when I last checked)
This would also allow APCu to safely start being used as a short-lived cache in front of memcached in places that didn't use it that way before (though https://github.com/krakjoe/apcu/issues/337 may become a bottleneck if that results in many more calls to APCu and hundreds of CPU cores)
Example use cases:
If APCu is used in front of redis/memcached or a fast enough database/service/etc, then users should have a way to indicate that it's fine to evict keys to make room for new keys (it may make sense to prefer evicting keys with an older last accessed time, fewer hits vs time unit, etc)
(Aside: Internally, memcached always allows for early eviction, when I last checked)
This would also allow APCu to safely start being used as a short-lived cache in front of memcached in places that didn't use it that way before (though https://github.com/krakjoe/apcu/issues/337 may become a bottleneck if that results in many more calls to APCu and hundreds of CPU cores)
Related to https://github.com/krakjoe/apcu/issues/369