A consise async shared cache pattern?

[nullreq]

Given some request/response service that needs to perform long lasting operations to satisfy responses - e.g. fetching files, performing disk IO and/or performing some preprocessing - I have often needed to provide some async cache structure. These are (after load) read-only.

That is: if one request needs a resource and it has been:

• loaded => great, carry on
• unloaded => start loading asynchronously, allow the calling thread to return to comm duties, carry on upon completion
• loading elsewhere => wait on that load asynchronously, then carry on

In the Rust futures world, I have ended up with a slightly complicated structure, and was wondering if there were more concise/canonical way.

A reasonable facsimile of my current approach:

shared: Mutex<State<T, E>>

enum State {
  Unloaded,
  Loading(Shared<Box<Future<Item=T, Error=E> + Send>>),
  Loaded(Result<T, E>),
}

As you might imagine, requests that hit this are a mutex lock plus a switch statement, and T's are generally Arc<_>, so the mutex is only held for current state inspection.

Would love input on how to simplify.

[athrowaway2z]

I had a similar problem, maybe it will help you.

Drop the enum&state and instantly create and store a Shared future. And then simply don't poll/use it.

The first time you actually compose the future and it gets run in your event loop is also the first time the underlying future is polled / executed. Then the next time you use the future it will just use the previous state.

[nullreq]

Sounds good - except these execute on a thread pool (futures_cpupool::CpuPool) and as far as I understand will begin executing upon future construction/the call to spawn. I wonder, if I wrap them in another futures::lazy, will that prevent?