Tatsuya Kawano

When I have time (maybe after work today. It is 6 AM now in my time zone), I will create a reproducing code for your original problem: ```console Request A...

> Future A is owned by Request A. Maybe we can avoid dropping Future A when Request A is dropped. I will try to move the ownership of Future A...

But to do so, I will have to remove the workaround for https://github.com/moka-rs/moka/issues/212. It is an optimization issue in `rustc`, which is not resolved yet (1.70.0-nightly 2023-03-07).

I started some experiments here: https://gitlab.com/moka-labs/moka-gh240-shared-init-future/moka/-/compare/master...shared-init-future It wraps the `init` future with `futures_util::future::Shared`, and stores it in the `waiter` hash table. ```rust pub(crate) type SharedInit = Shared Entry; ``` and...

Hi. Thank you for using moka. > I'm looking for a function that has the same behavior as `and_try_compute_with` but the same concurrency as `or_insert_with`. I believe you can use...

> Also, one question about this approach: Can multiple calls to remove at the same time return copies of the value, or will only one call get the value and...

> Is there a way that I can say `if(this closure had to block and wait for A) return Op::Nop` at the top of my closure? No. Currently, moka does...

Thank you for explaining. I have a better understanding of the issue now. > 2. Ensure that multiple update operations cannot happen at once. This is to prevent unnecessary load...

> Right now, I'm simply removing the key before running the closure, but this resets the TTL on the value. I don't want to do that. In the above code...

> I don't really mind if 'B' blocks during steps 3-7 but yes, returning immediately would be the ideal behavior. OK. For now, I would not have enough time to...