Skip to content

free operation queue semaphore in process snapshot chunk and when hitting error in handleSnapshot that prevents us from calling process snapshot chunk #1420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Oct 24, 2024

Conversation

lazynina
Copy link
Member

No description provided.

@lazynina lazynina marked this pull request as ready for review October 21, 2024 18:23
@lazynina lazynina requested a review from a team as a code owner October 21, 2024 18:23
@@ -1255,6 +1255,8 @@ func (bc *Blockchain) LatestLocator(tip *BlockNode) []*BlockHash {
}

func (bc *Blockchain) HeaderLocatorWithNodeHash(blockHash *BlockHash) ([]*BlockHash, error) {
bc.ChainLock.RLock()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just give me a comment on why we need the locks here.

lib/server.go Outdated
@@ -1658,6 +1687,9 @@ func (srv *Server) _handleSnapshot(pp *Peer, msg *MsgDeSoSnapshotData) {
"attempt to HyperSync from the beginning. Local db checksum %v; peer's snapshot checksum %v",
checksumBytes, srv.HyperSyncProgress.SnapshotMetadata.CurrentEpochChecksumBytes)))
if srv.forceChecksum {
// Free up a slot in the operationQueueSemaphore, since we hit an error and it won't be freed
// by processing the snapshot chunk.
srv.snapshot.FreeOperationQueueSemaphore()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my fixme above. Seems like a bug to call it here?

lib/snapshot.go Outdated
}

mainDbMutex.Lock()
// TODO: I think we don't need to hold the chain lock. We can have multithreaded writes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is correct. Key-value pairs in snapshot chunks should never overlap, and we never fetch the same snapshot more than once so I think this is OK. The lock was probably put here to be extra cautious.

lib/server.go Outdated
@@ -1441,13 +1441,16 @@ func (srv *Server) _handleSnapshot(pp *Peer, msg *MsgDeSoSnapshotData) {
msg.SnapshotChunk[0].Key, msg.SnapshotChunk[len(msg.SnapshotChunk)-1].Key, len(msg.SnapshotChunk),
msg.SnapshotMetadata, msg.SnapshotChunk[0].IsEmpty(), pp)))
// Free up a slot in the operationQueueSemaphore, now that a chunk has been processed.
srv.snapshot.FreeOperationQueueSemaphore()
// srv.snapshot.FreeOperationQueueSemaphore()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some comments in this file as FIXMEs because I couldn't comment on the lines that were unchanged in the PR. See my edited PR here:

https://github.com/deso-protocol/core/pull/1423/files

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also tried a weird alternative with defer that may be less error-prone. Check it out up to you if you want to change it.

…1423)

* make GetUtxoViewAndUtxoOpsAtBlockHash public (#1422)

* review

* remove fixmes and add comments

---------

Co-authored-by: Lazy Nina <[email protected]>
Co-authored-by: Lazy Nina <[email protected]>
@lazynina lazynina merged commit 3cc2234 into main Oct 24, 2024
3 checks passed
@lazynina lazynina deleted the ln/free-operation-queue-semaphore-in-process-chunk branch October 24, 2024 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants