Skip to content

Conversation

@TheBlueMatt
Copy link
Contributor

Based on #6595

@dcousens
Copy link
Contributor

For those unaware, you can view the diff without whitespace changes by adding ?w=0 to the url.

utACK.

@btcdrak
Copy link
Contributor

btcdrak commented Sep 10, 2015

utACK

@sdaftuar
Copy link
Member

What do you think about moving the calls to mempool.removeForReorg() that are inside ActivateBestChainStep() to ActivateBestChain()? I think that would probably make things a bit cleaner.

@TheBlueMatt
Copy link
Contributor Author

@sdaftuar I'd feel bad calling removeForReorg and iterating over the mempool after each new block (instead of only if we actually called Disconnect). It would simplify the code some, but not much? I dunno, do you think its worth it?

@sipa
Copy link
Member

sipa commented Sep 10, 2015

It should be in Step, I think. In between the calls to Step cs_main is released, so the result is observable. I don't think we want to release cs_main while the mempool is in an inconsistent state.

@TheBlueMatt
Copy link
Contributor Author

I believe @sdaftuar meant to put the call before cs_main was released in ActivateBestChain so that you dont have to do it before every return statement.

@sipa
Copy link
Member

sipa commented Sep 10, 2015

Ah, no opinion.

@sdaftuar
Copy link
Member

Yeah that's what I had in mind, except my thought was to continue to use the blocksDisconnected bool to signal the caller it should make the call to mempool.removeForReorg() (ie pass in a new bool by reference and populate it in ActivateBestChainStep). It just seems less error prone for future changes to the code to not have to guard every place ActivateBestChainStep returns (and since ActivateBestChainStep asserts that the caller holds cs_main, so it doesn't seem inherently strange to do it in the caller).

@sdaftuar
Copy link
Member

@TheBlueMatt: this is what I had in mind: sdaftuar@cc4b7b0

Eh, maybe it's just personal taste which formulation is better, you can take it or leave it. I'll think about additional testing.

@petertodd
Copy link
Contributor

Looks like this needs a rebase now that #6654 is merged.

@TheBlueMatt
Copy link
Contributor Author

This needs a more involved rebase, because it requires a more thourough checking that it is still correct. Closing for now, someone can come along and fix it again later.

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants