Wrap ChainSyncer::state in an Arc<Mutex<_>> and set it to Follow accordingly #914
Conversation
| if *self.state.lock().await == ChainSyncState::Bootstrap { | ||
| if let Some(best_target) = self.select_sync_target().await { | ||
| self.schedule_tipset(best_target).await; | ||
| self.state = ChainSyncState::Initial; | ||
| *self.state.lock().await = ChainSyncState::Initial; |
There was a problem hiding this comment.
I believe this keeps the lock and will deadlock here, has this been tested?
There was a problem hiding this comment.
Not tested, but I'm quite certain that if *self.state.lock().await does not keep the guard around since it's not bound to a variable, if that's what you're referring to. (playground that uses std's Mutex)
There was a problem hiding this comment.
I've had issues with async-std mutexes holding the lock in this exact case in the past, not sure if it's changed or only applies to RwLock but can double check
There was a problem hiding this comment.
nvm, there was a specific case where it deadlocked similar to this, and moving the read outside of the if removed the deadlock, I just tested and this works
There was a problem hiding this comment.
Oh yeah, I can totally see that happening. Thanks for pointing it out either way, I could have easily messed this up
| @@ -78,7 +78,7 @@ impl Default for SyncConfig { | |||
| /// messages to be able to do the initial sync. | |||
| pub struct ChainSyncer<DB, TBeacon, V, M> { | |||
| /// State of general `ChainSync` protocol. | |||
| state: ChainSyncState, | |||
| state: Arc<Mutex<ChainSyncState>>, | |||
There was a problem hiding this comment.
is mutex over rwlock required?
There was a problem hiding this comment.
It is not, but does RwLock have any benefits if we're not expecting concurrent reads?
There was a problem hiding this comment.
Yeah I just was asking because there doesn't seem to be a reason to have the additional constraint (just thinking for future proofing)
It's definitely fine if this stays as is, this will probably be replaced in the future anyway
Summary of changes
Changes introduced in this pull request:
ChainSyncer::statein anArc<Mutex<_>>::FollowwhenSyncWorker::synccompletes succesfullyReference issue to close (if applicable)
Closes #876