entries are leaked when sync::Cache is dropped

[igorzi]

Simple repro below (Foo is not dropped when the cache is dropped).

use moka::sync::Cache;

struct Foo {}

impl Drop for Foo {
  fn drop(&mut self) {
    eprintln!("Foo dropped");
  }
}

fn main() {
  let foo = Arc::new(Foo {});
  let cache = Cache::builder().build();
  {
    cache.get_with("foo", move || {
      foo
    });
  }
  drop(cache);
}

[igorzi]

Note that if I add cache.run_pending_tasks(); right before drop(cache); - the entries do get dropped.

[tatsuya6502]

Thanks for reporting!

I believe this is due to the spec that crossbeam-epoch crate does not guarantee to run the destructor of the pointed object.

https://docs.rs/crossbeam-epoch/0.9.18/crossbeam_epoch/struct.Guard.html#method.defer_destroy

There is no guarantee when exactly the destructor will be executed. The only guarantee is that it won’t be executed until all currently pinned threads get unpinned. In theory, the destructor might never run, but the epoch-based garbage collection will make an effort to execute it reasonably soon.

We have been struggling with this spec (notes) and added some mitigations. Now I am adding another mitigation via #384, but the new unit tests are a bit flaky.

Let me struggle a bit longer to see if I can stabilize them.

[tatsuya6502]

I am not totally sure if I have stabilized the flaky tests, but I am going to merge #384 and will see how these jobs will go. If everything goes well, I will publish a new version moka@v0.12.4 to crates.io. Hopefully that will happen in the next few days.

Also I created the following issue to evaluate an alternatives of crossbeam-epoch:

• Try seize as a replacement of crossbeam-epoch? #385

Thanks again for reporting the issue!

[igorzi]

Thanks!

[tatsuya6502]

FYI, I just published moka@v0.12.4 to crates.io.