This PR doesn't work but shows my train of thought.
We change dispatch into a "normal" function that delegates directly to the "doer" functions. I already tested (see do_test) that the basic concept works -- the futures get executed and calls can overlap this way.
However, I rediscovered why we need the dispatch loop!
It's fundamentally because of the relationship between transactions and stores. Transactions have a reference to their store, so the store must outlive the transaction. In particular the RWLockGuard in kv::{Read,Write}Transaction.
My thought was that the RWLock would let us get around this, but it does not. What it weakens is the single writer requirement. The reference requirement remains.
This PR doesn't work but shows my train of thought.
We change
dispatchinto a "normal" function that delegates directly to the "doer" functions. I already tested (seedo_test) that the basic concept works -- the futures get executed and calls can overlap this way.However, I rediscovered why we need the dispatch loop!
It's fundamentally because of the relationship between transactions and stores. Transactions have a reference to their store, so the store must outlive the transaction. In particular the
RWLockGuardinkv::{Read,Write}Transaction.My thought was that the RWLock would let us get around this, but it does not. What it weakens is the single writer requirement. The reference requirement remains.