Is moka::future::Cache blocking insert has similar efficiency comparing to the moka::sync::Cache insert?

[LMJW]

Hi @tatsuya6502 Have some question regarding to blocking insert for moka::future::Cache.

I saw in the doc, https://docs.rs/moka/latest/moka/future/struct.BlockingOp.html#method.insert , this is recommanded to be used when need to insert from synchronous code.

I am curious if this operation has same efficiency as sync cache insert operation( https://docs.rs/moka/latest/moka/sync/struct.Cache.html#method.insert)

I did some very basic source code dive, looks the blocking insert for future cache underline depends on blocking_schedule_write_op code which has the same code as schedule_write_op in sync cache. So I imaging the blocking insert in future cache is as efficient as insert in sync cache? But just want to double check with you if this is true. :)

Thanks in advance!

[tatsuya6502]

Hi @LMJW

I did some very basic source code dive, looks the blocking insert for future cache underline depends on blocking_schedule_write_op code which has the same code as schedule_write_op in sync cache. So I imaging the blocking insert in future cache is as efficient as insert in sync cache?

You are right (as of Moka v0.10.0).

However, I was thinking to deprecate blocking() method of future::Cache in v0.11.0 and eventually remove. This is because future::Cache in v0.11.0 will no longer be able to share the same base_cache::BaseCache implementation with sync::Cache. In order to support some features like #228 (comment), future::Cache should start to use async version of locks throughout its internal codes. It is not possible to call an async lock's lock().await from outside of async context.

Let me think a bit more, to see if there is a way to keep blocking() method in future versions of future::Cache.

But if not, you will have to use something like block_on method of futures_executor like the followings:

// Create a cache.
let cache = moka::future::Cache::new(100);

// In your synchronous code, insert an entry using `block_on`
// and async version of `insert`.
futures_executor::block_on(cache.insert(1, 1));

// get the value.
println!("{:?}", cache.get(&1));

[LMJW]

Hi @tatsuya6502 Thanks for your information.

Just wondering, is the new refactoring aiming for supporting some new features and performance improvement? Also is it possible to keep the blocking to be at key level rather than futures_executor::block_on(cache.insert(1, 1)); in the new revision?

Feels the executor block on will be blocking at the cache level rather than the key level.

I feel it would be good to keep the blocking method since it might have the case where the cache need to be executed in a sync context. But I might missing the context about the changes.

[tatsuya6502]

Also is it possible to keep the blocking to be at key level rather than futures_executor::block_on(cache.insert(1, 1)); in the new revision?

Feels the executor block on will be blocking at the cache level rather than the key level.

The blocking happens at key level. It calls the async version of insert method of moka::future::Cache from a synchronous context. The async insert does key level blocking using an async lock.

I think my previous message was misleading. I wanted to show a common way to call async fn in synchronous context, instead of a moka-specific way. The above block_on was provided by futures-executor crate, and many async library crates, including Tokio, async-std and actix-rt, provide similar functions. (Doc for block_on from Tokio). These functions will run the given future on the current thread, blocking until it is complete, and yielding its resolved result. Here is a detailed explanation about block_on: https://rust-lang.github.io/async-book/01_getting_started/04_async_await_primer.html

[LMJW]

Hi @tatsuya6502 Thanks for your explaination. That is very insightful. I am glad even using the block_on it is still key level blocking. This is excellent. Will go through the links you've provided. Thanks!