Big +1 on this in general. I would also relax our guarantees on operations submitted from the same thread. Currently we guarantee that sequential invocations of async operations happen in the same order. I think that if a user wants such guarantees, he must define these dependencies explicitly by calling chain() on returning futures.
This change will significantly improve cache operations performance in async mode. 3) Sync operations normally* should not* be implemented through async. This > is a long story - if we delegate to async, then we have to bother with > additional threads, associated back-pressure control and all that crap. > Sync call must be sync unless there is a very strong reason to go through > async path. > Not sure about this, though. In most cases a cache operation implies request/response over the network, so I think we should have explicit synchronous counterparts only for methods that are guaranteed to be local.
