Skip to content
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

Follow-up on #1419 #1531

Merged
merged 3 commits into from
Aug 2, 2022
Merged

Follow-up on #1419 #1531

merged 3 commits into from
Aug 2, 2022

Conversation

serban300
Copy link
Collaborator

Addressing the comments in #1419

I spent a lot of time thinking about naming. NoopOption was the best name I could find so far to make ParaHashAtSource more generic although it doesn't seem ideal.

Also it would be nice to define max_head_id as a NoopOption from the start, but I didn't do it since this way we would have to create an Arc<Mutex<NoopOption>> and it would be less efficient (because we would have to lock the mutex even if max_head_id == Noop::None, which is not needed now). We could have something more efficient using atomic variables, but that would increase the complexity of the code.

@serban300 serban300 requested a review from svyatonik August 1, 2022 15:01
@serban300 serban300 self-assigned this Aug 1, 2022
- Make `ParaHashAtSource` more generic
- Modify `on_chain_parachain_header` to return `HeaderId`
- Shortening variable names

Signed-off-by: Serban Iorga <[email protected]>
Change ParachainsSource::max_head_id to Arc<Mutex<NoopOption>>

Signed-off-by: Serban Iorga <[email protected]>
@serban300
Copy link
Collaborator Author

Also it would be nice to define max_head_id as a NoopOption from the start, but I didn't do it since this way we would have to create an Arc<Mutex<NoopOption>> and it would be less efficient (because we would have to lock the mutex even if max_head_id == Noop::None, which is not needed now). We could have something more efficient using atomic variables, but that would increase the complexity of the code.

Actually this mutex doesn't seem to be heavily used and changing it to Arc<Mutex<NoopOption>> doesn't seem to imply a significant penalty. I added a commit that does this.

Copy link
Contributor

@svyatonik svyatonik left a comment

Choose a reason for hiding this comment

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

Please fix the impl of Ord/PartialOrd and then it's fine to merge! Thank you!

}
}

impl<Hash: Eq, Number: Ord> Ord for HeaderId<Hash, Number> {
Copy link
Contributor

Choose a reason for hiding this comment

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

IIUC this breaks the exactly one of a < b, a == b or a > b is true rule (https://doc.rust-lang.org/std/cmp/trait.Ord.html). Can we, please, add hash to comparison as well?

Copy link
Contributor

Choose a reason for hiding this comment

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

(same for PartialOrd)


/// Shared updatable reference to the maximal parachain header id that we want to sync from the
/// source.
pub type RequiredHeaderIdRef<C> = Arc<Mutex<Option<HeaderIdOf<C>>>>;
pub type RequiredHeaderIdRef<C> = Arc<Mutex<NoopOption<HeaderIdOf<C>>>>;
Copy link
Contributor

Choose a reason for hiding this comment

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

This actually seems like a redundant change - we'll be only using Some or None here. right? :) So we don't need this Noop at all. But I'm fine with leaving it as is :)

@@ -271,3 +271,28 @@ where
},
}
}

/// An extension over rust's `Option` that adds an extra possibility: `Noop`.
Copy link
Contributor

Choose a reason for hiding this comment

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

I would rather made it less generic - like something you have suggested originally (or even enum AvailableHeader<T> { Available(T), Missing, Unavailable }, where Missing means None). It will (imo) add some context to the code + we may add more useful documentation to each option.

But please don't consider my opinion as the requirement - I'm fine with either solution, so please make your own decision here :)

@svyatonik svyatonik merged commit 868e782 into paritytech:master Aug 2, 2022
serban300 added a commit to serban300/parity-bridges-common that referenced this pull request Mar 27, 2024
* Parachains source cosmetic changes

- Make `ParaHashAtSource` more generic
- Modify `on_chain_parachain_header` to return `HeaderId`
- Shortening variable names

Signed-off-by: Serban Iorga <[email protected]>

* Change ParachainsSource::max_head_id type

Change ParachainsSource::max_head_id to Arc<Mutex<NoopOption>>

Signed-off-by: Serban Iorga <[email protected]>

* code review changes
serban300 added a commit to serban300/parity-bridges-common that referenced this pull request Apr 8, 2024
* Parachains source cosmetic changes

- Make `ParaHashAtSource` more generic
- Modify `on_chain_parachain_header` to return `HeaderId`
- Shortening variable names

Signed-off-by: Serban Iorga <[email protected]>

* Change ParachainsSource::max_head_id type

Change ParachainsSource::max_head_id to Arc<Mutex<NoopOption>>

Signed-off-by: Serban Iorga <[email protected]>

* code review changes
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