Implements a mechanism to lock/unlock the SortedListProvider
and bags-list iter
#6510
+207
−3
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.
Implements a mechanism to lock/unlock the
SortedListProvider
and bags-list iter.WIP and currently implementing Option 1.
Goals:
trait SortedListProvider
to allow locking and unlocking the ordering of the list's elements.SortedListProvider::iter()
implementation of the bags-list.Option 1.
Return err
List::ReorderingNotAllowed
whenever a bags-list extrinsic orSortedListProvider
method is called that may affect the iterator ordering while the lock is set, ie:SortedListProvider::on_insert
(inserting ID in the list will change the iter)SortedListProvider::on_update
(updating an ID score may cause a rebag)SortedListProvider::on_remove
(removing an ID in the list will change the iter)BagsList::call::rebag
BagsList::call::put_in_front_of
BagsList::call::put_in_front_of_other
Even tough this approach is simple to implement and can be implemented all at the bags-list level, it may be too strict as some of the sorted list provider method calls may not affect the iter ordering or their implementation could be refactored to apply score mutations without changing the iter ordering e.g.
on_update
scores without rebag,on_remove
do not remove the node from the list, etc.Option 2.
Same as option 1, but refactor the sorted list provider implementation to ensure that all list mutations happen but ensure the list ordering does not change if the lock is set.