Create new BlockManager architectural component #5
Conversation
Signed-off-by: Adam Ludvik <ludvik@bitwise.io>
| The blocks passed must form a branch meaning they satisfy the following | ||
| conditions: | ||
|
|
||
| 1. The first block's parent is present |
There was a problem hiding this comment.
Does present mean that the parent block is already in the block manager? It is ambiguous as to whether it is that or "present in the List".
There was a problem hiding this comment.
I read that to mean that the parent of the list[0] element is already present in tree managed by the block manager.
| `unref_block` A now, the block manage will ensure it is not actually dropped, | ||
| since there is still an open hold on the block. Finally, when the chain | ||
| controller takes ownership of B, it can send a signal back to the completer | ||
| that it has been received and the completer can release its hold. |
There was a problem hiding this comment.
"completer can release its hold": Does the completer have a hold on the block or is it the Block Manager?
There was a problem hiding this comment.
And what does it mean for the chain controller to take ownership of B? Would the completer actually be passing a reference to the controller for an object managed by the block manager?
| the block is in | ||
|
|
||
| A block in a store and not the __main cache__ has an implicit reference count | ||
| of 1 if it is not the tip of the branch in the store. If it is the tip of the |
There was a problem hiding this comment.
of 1 or of at least 1? (viz holds placed by other objects)
|
|
||
| Internally, the block manager consists of: | ||
|
|
||
| - A __main cache__ which, at a minimum, contains all blocks that have not been |
There was a problem hiding this comment.
is main cache a block store?
There was a problem hiding this comment.
Hi, @dcmiddle . Since I am implementing this right now, I thought I should respond. The main cache is in-memory and is not a block store. It is a logical space. Right now in my implementation it is a HashMap of block ids to Block - reference count tuples, wrapped in a lock. Specifically Rc<RwLock<HashMap<String, (Rc, i64, i64)>>>.
|
|
||
| In addition to the __block manager__ class and __block store__ interface, a | ||
| __commit store__ class was created The commit store is a __block store__ | ||
| implementation that can be added to the block tree for persisting committed |
There was a problem hiding this comment.
What does it mean to say that the commit store can be added to the block tree? The block tree class has a member which which implements store? Does a tree have to be instantiated with a store implementation? I'm generally unclear on the relationship between block stores and trees. Maybe a fuller description of the block tree class would help.
There was a problem hiding this comment.
A block store is just a place to persist blocks, specifically a single branch of blocks. Multiple stores can be added to the manager and branches can be persisted to multiple stores. So, for example, you could have a faster local disk store and slower, perhaps network backed, store for archiving very old blocks.
| - Persisting blocks to a __block store__. | ||
|
|
||
| In addition to the __block manager__ class and __block store__ interface, a | ||
| __commit store__ class was created The commit store is a __block store__ |
There was a problem hiding this comment.
Is the commit store a member of the block manager?
There was a problem hiding this comment.
The block manager has a map of store names to stores. The commit store would be one such member of that map.
| prevent blocks from being dropped when they are transferred from the completer | ||
| to the chain controller. | ||
|
|
||
| Assume that the chain controller has a block A and that the completer has just |
There was a problem hiding this comment.
Do the chain controller and completer both hold references to the same block manager or does the chain controller own the block manager? I assume the former. In which case the controller and the completer must both signal the block manager before / after certain operations.
There was a problem hiding this comment.
Both the chain controller and completer hold references. This is to allow the completer to make sure blocks arrive at the chain controller with all their predecessors and to ensure both the chain controller and completer are in sync wrt what blocks are present.
| completer were to just pass the chain controller B through a queue or shared | ||
| memory, the chain controller could decide to `unref_block` A before it receives | ||
| B, causing B to have a missing predecessor when it arrives at the chain | ||
| controller. Instead, the completer first places a `ref_block` on A, causing and |
There was a problem hiding this comment.
To clarify regarding above comment about ownership vs. signaling of the block manager...
"Instead, the completer first calls the block manager to place a ref_block on A causing and"
| - The block id of the block that is in the store | ||
| - A list of names of stores that the block is in | ||
| - A reference count of blocks that depend on the anchor but are not in a store | ||
| the block is in |
There was a problem hiding this comment.
This seems confusing to have reference counting on the anchor and on the block. Would it make sense to just have reference counting managed by the tree? I'm assuming all blocks are referenced in the tree(s)?
Signed-off-by: Adam Ludvik ludvik@bitwise.io