Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the introduction of epochs, the Membership type is no longer static. We need to update the Membership on each epoch. This requires wrapping Membership in Arc<RwLock<..>>. Hence, all Membership methods would need to acquire a read lock, which requires making the membership functions async.
Since the current functions are not async, they block the thread to acquire the lock, which is dangerous. Some sequencer tests also return the following error:
Cannot block the current thread from within a runtime. This happens because a function attempted to block the current thread while the thread is being used to drive asynchronous tasks.
So, to make things work , we should make these functions async and this PR implements these changes.
There has also been a discussion about Hotshot managing the locks on the Membership type and handle the call to the update() function on Membership at every new epoch. This approach is much better IMO, and I believe it would also require making these functions async.