async cache population

[barkanido]

I am designing a service that uses a cached configuration, backed by Redis. The cache is "dummy" in the sense that it needs to be populated by the caller (this crate is an example).

The following should take place during the execution of an existing task:

1. Grab a message from an async channel.
2. perform a computation on this message that involves a read from the cache.
3. If the cache read is a miss (TTL based entry eviction), the task should yield a computation of the cache entry.
4. since this computation is blocking (a Redis read operation) the task might (in the case of a cache miss) perform an expensive I/O.

I have already understood (thanks to @Darksonn ) that those kinds of action should be performed by using task::spawn_blocking. But the parent task is expected to be run with a simple tokio::spawn since most of the time it does do any blocking I/O computations.

My question is: Is it a good practice to combine I/O blocking tasks with non-blocking tasks and will Tokio do the right thing here?
What should be the sketch of combining an async Redis client with Tokio support like redis with a simple TTL cache?

[Darksonn]

To be clear, a Redis read operation is not necessarily considered blocking. This would only be the case if you used a library that did not use async IO for talking to the Redis server. Or in the words of my blog post on blocking, it would only be blocking if it performs the IO without an await.

I recommend you just make sure to use async IO, because then you will not need spawn_blocking.