-
Notifications
You must be signed in to change notification settings - Fork 109
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
Conversation
…ting error in handleSnapshot that prevents us from calling process snapshot chunk
…bytes if checksum isn't disabled
@@ -1255,6 +1255,8 @@ func (bc *Blockchain) LatestLocator(tip *BlockNode) []*BlockHash { | |||
} | |||
|
|||
func (bc *Blockchain) HeaderLocatorWithNodeHash(blockHash *BlockHash) ([]*BlockHash, error) { | |||
bc.ChainLock.RLock() |
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
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:
There was a problem hiding this comment.
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]>
No description provided.