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

More bugfixes & some suggested changes #11

Merged
merged 8 commits into from Mar 26, 2024
Merged

Conversation

matheus23
Copy link
Member

@matheus23 matheus23 commented Mar 22, 2024

In this PR the individual commits should read really nicely!
So I'd recommend reviewing by commit.

There's mostly bugfixes, some solved FIXMEs, which I'd expect be uncontroversial changes (ignoring possible bugs I've introduced).
But there's also some changes that are more subjective:

  • Take command: &str instead of command: String in Store::get_chain: I think this makes sense, because get chain is mostly a lookup, it doesn't need ownership to construct the return value.
  • Turn the Iterator::try_fold call in Invocation::check into a for loop: I think that just reads slightly easier & is more idiomatic in rust. reverted this, it's in the history should we need it :)

@matheus23 matheus23 self-assigned this Mar 22, 2024
@expede
Copy link
Member

expede commented Mar 22, 2024

Turn the Iterator::try_fold call in Invocation::check into a for loop: I think that just reads slightly easier & is more idiomatic in rust.

Aren't they both idiomatic? The docs seem to imply that they are, at least — possibly even encouraging folds as I read it 🤔 Googling around, it looks like there's some debate about which to use. Stylistically, I like that try_fold expresses its intention without having to read the entire code block.

I'm sure that there's cases where each does better, but I've also seen a few benchmarks where iterator methods like fold outperform loops (maybe because they're more structured?)

@matheus23
Copy link
Member Author

Okay, sure. I personally found it harder to read, but I have pretty weak opinions on that one.

@expede
Copy link
Member

expede commented Mar 26, 2024

but I have pretty weak opinions on that one

Oh yeah, same here. I was just surprised by the claim!

@@ -79,7 +80,7 @@ pub struct MemoryStore<
V: varsig::Header<C> = varsig::header::Preset,
C: Codec + TryFrom<u64> + Into<u64> = varsig::encoding::Preset,
> {
inner: Arc<RwLock<MemoryStoreInner<DID, V, C>>>,
inner: Arc<Mutex<MemoryStoreInner<DID, V, C>>>,
Copy link
Member

Choose a reason for hiding this comment

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

To account for starvation I guess?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, due to this conversation. I think RwLocks being able to cause deadlocks is... not great. Defaulting to Mutex seems like the better option 👍

Copy link
Member

@expede expede left a comment

Choose a reason for hiding this comment

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

Thanks @matheus23

@matheus23
Copy link
Member Author

I only rebased the same changes on the newest commits from the v1.0-rc1 branch, so the changes you reviewed are the same!
Also ran cargo test --all-features and that is happy, so merging this ✌️

@matheus23 matheus23 merged commit 5dbd296 into v1.0-rc.1 Mar 26, 2024
5 of 9 checks passed
@matheus23 matheus23 deleted the matheus23/v1.0-2 branch March 26, 2024 11:33
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.

None yet

2 participants