Porvide a mechanism to lock some entry

[Austaras]

Currently I use moka as shared state of my application to avoid high memory usage. However sometimes if a long lived future holds a state for too long, it may get evicted and lose sync with other futures. I'd like to have something like

async fn get_or_init_locked(&self, key: K) -> LockResult<V>

And when LockResult is dropped, that entry is free to update to evict.

[tatsuya6502]

@Austaras

Thank you for the idea. (and sorry for a late reply)

I think locking/delayed eviction will not fit very well to the current future::Cache behavior. So if we want to support them, we probably need to create a different cache implementation.

We will need to decide what the new cache should do in the following cases:

• Expiration:
  • An entry can be expired when TTL (time-to-live) or TTI (time-to-idle) timer exceeded:
  • With the current spec of future::Cache, get will never return an expired entry.
  • What the new cache should do?
    • Perhaps return an expired entry if it is locked?
• Replacing:
  • An entry can be replaced by calling insert on the same key.
  • With the current spec, insert always succeeds and replaces the old entry.
  • What the new cache should do?
    • Perhaps the cache should not provide insert method at all as there will be get_or_init_locked as an alternative?
• Invalidation:
  • An entry can be invalidated by invalidate, invalidate_all, etc.
  • With the current spec, invalidate etc. always succeeds and removes the entry, and get will never return an invalidated entry.
  • What the new cache should do?
    • Perhaps invalidate should fail if the entry is locked?
    • Or invalidate will schedule the removal of the entry after the lock is released?

Do you use these features? If so, what do you expect the new cache to do in these cases?