-
Notifications
You must be signed in to change notification settings - Fork 37.7k
Final Preparation for main.cpp Split #9183
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
Conversation
utACK c53fc42 |
Core Review ACK c53fc42cd7c57c75940e6ec593973e3f0ad69374. |
} | ||
|
||
CValidationState state; | ||
if (!ProcessNewBlockHeaders(headers, state, chainparams, &pindexLast)) { // We should call this without cs_main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems if one fails we don't actually know which? Or is there some async event?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thats true, though I dont think any code actually needs to know which currently? If its needed at some point its easy to add an async event and/or additional return value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stale comment? As far as I can tell, cs_main is not locked here.
Not sure if this means "TODO: Don't call without cs_main" or "make sure not to call this with cs_main"
{ | ||
LOCK(cs_main); | ||
for (const CBlockHeader& header : headers) { | ||
if (!AcceptBlockHeader(header, state, chainparams, ppindex)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is probably fine now, but reusing state and assuming that it's only interesting if AcceptBlockHeader fails seems like it's asking for future bugs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm...I'm sure this isnt the only place we do this. Would definitely need an audit to figure out all the places this is true if we ever want to change state meaning.
This will allow NotifyHeaderTip to be called from an AcceptBlockHeader wrapper function without holding cs_main.
c53fc42
to
711fb0b
Compare
Rebased after merge of #8930. |
utACK 711fb0bb192e6b9a6ac8c53c35f12be6d7216df7 |
cautious ACK This looks good to me, I code reviewed, and did some light testing. I was a bit hesitant about moving NotifyHeaderTip before the rest of the header processing, but that seems to be mostly async behavior. |
utACK 711fb0b |
@theuni Comments? |
|
||
CBlockIndex *pindex = NULL; | ||
CValidationState state; | ||
if (!AcceptBlockHeader(cmpctblock.header, state, chainparams, &pindex)) { | ||
if (!ProcessNewBlockHeaders({cmpctblock.header}, state, chainparams, &pindex)) { // We should call this without cs_main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same
utACK 711fb0bb192e6b9a6ac8c53c35f12be6d7216df7. The comment nits can be fixed later. |
711fb0b
to
2c8c57e
Compare
Fixed @theuni's documentation comments. |
} | ||
return error("invalid header received"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe print the state here (ie use FormatStateMessage(state), maybe func too) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AcceptBlockHeader already does a bunch of printing. And while this could maybe be cleaned up, probably a topic for another PR, I think.
|
||
CBlockIndex *pindex = NULL; | ||
CValidationState state; | ||
if (!AcceptBlockHeader(cmpctblock.header, state, chainparams, &pindex)) { | ||
if (!ProcessNewBlockHeaders({cmpctblock.header}, state, chainparams, &pindex)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why {} around cmpctblock.header ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the {} creates the vector that ProcessNewBlockHeaders takes, instead of a single header as AcceptBlockHeader does (note that it makes a copy of the header, but nbd, I think).
utACK 2c8c57e besides my little nits. |
utACK 2c8c57e |
2c8c57e Document cs_main status when calling into PNB or PNBH (Matt Corallo) 58a215c Use ProcessNewBlockHeaders in CMPCTBLOCK processing (Matt Corallo) a8b936d Use exposed ProcessNewBlockHeaders from ProcessMessages (Matt Corallo) 63fd101 Split ::HEADERS processing into two separate cs_main locks (Matt Corallo) 4a6b1f3 Expose AcceptBlockHeader through main.h (Matt Corallo)
} | ||
|
||
CValidationState state; | ||
if (!ProcessNewBlockHeaders(headers, state, chainparams, &pindexLast)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why name it such when the headers won't necessarily be new?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To mirror the naming of ProcessNewBlock.
Lost while backporting bitcoin#9183
Lost while backporting bitcoin#9183
Lost while backporting bitcoin#9183
Based on #8930, the only thing left to do after this to split main.cpp into main and net_processing is a single move-only commit.
After #8930, the only remaining changes are tweaks to pull header-processing-logic out of net code and into a function exposed through main.h.