Unblock safe store reads (no need for spin lock).
Closed this issue · 3 comments
Many objects, including blocks and transactions, can be safely read even during write without possibility of corruption. The exceptions are metadata that is modified after the initial objects have been indexed. The file is trimmed to last logical size upon closing, but records are never trimmed while the store is open, they are only un-indexed.
- tx output spender heights, which is currently read only while write is precluded (in validation).
- tx height, which is used to store height and validation flags (so must be read/written atomically).
- tx position, which is used to indicate position and confirmation (so must be read/written atomically).
- fetch_transaction_position (requires above atomicity)
- fetch_output (see spender height issue above)
- last_height (safe)
- filter_blocks and filter_transactions (safe)
- fetch_locator_block_hashes and fetch_locator_block_headers (safe)
- fetch_spend (atomic addition to hash table)
- fetch_history (atomic addition to hash table, not across txs/blocks)
- fetch_stealth (atomic addition to array, not across txs/blocks)
Futures (these are safe now but won't be due to height overloading):
- header height, will be used to store height and to indicate chain (so must be read/written atomically).
- block and merkle_block (apart from header height) and eventually compact_block.
- fetch_block_height (requires above atomicity)
To implement atomicity without overextending locks, tx/block heights and positions must be read in construction of the transaction_result and block_result objects. This will be a slight performance hit in exchange for a major performance benefit (100% successful read while write).
Unsafe:
- fetch_block_locator (selection is by height/chain)
This can be resolved by caching the locator. It can be updated for each new block and incremented when it requires expansion (rarely). Ultimately this should be part of chain _state.
All complete except for movement of fetch_locator and subsequent dead code removal. #366
Because of the synchronous nature of queries that never spin (sleep) there is no reason to use a callback model. All queries can be invoked inline. This would an interface change and therefore would be applicable to v4.0. This also implies that fast_chain and safe_chain can be consolidated in 4.0.
Moving fetch_block_locator to new issue and calling this one complete.