This repository has been archived by the owner on Sep 3, 2021. It is now read-only.
For discussion - deloop dispatch #192
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The openTransaction RPC fundamentally cannot work this way due to the lifetime parameters in kv::Store::read() and write(): You can't hold a guard beyond a stack frame because it needs to live as long as the store that creates it and there's no way to statically prove that to the compiler. I can think of a few paths for exploration: 1. Have the transactions refcount the store. 2. Have the store own the transactions. This makes a lot of sense conceptually I think, but I think it would require big changes to dag::Read/Write and db::Read/Write, which are designed to wrap/own the lower level stores.
phritz
reviewed
Sep 23, 2020
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.