Looking at the code in rpcmining.cpp with respect to locking of cs_main when creating new blocks, I observe two things:
-
The code for setgenerate locks cs_main only very briefly for calling IncrementExtraNonce. Does that mean that in theory, a block could have arrived between the call to CreateNewBlock and IncrementExtraNonce, thus making IncrementExtraNonce write out a wrong height into the coinbase? I realise that this is only for regtest mode and thus a non-issue, but it seems "wrong" nevertheless.
-
The code for getblocktemplate, on the other hand, locks cs_main over most of its length. Because of this, the usage of pindexPrevNew (with a comment "to avoid races") seems unnecessary. Or do I miss anything here?
None of these is an issue I would consider "critical" - but both seem a bit inconsistent to me. Unless I miss some details here, the code in its current form seems, at least, confusing about how locking "should" be done.
Looking at the code in
rpcmining.cppwith respect to locking ofcs_mainwhen creating new blocks, I observe two things:The code for
setgeneratelockscs_mainonly very briefly for callingIncrementExtraNonce. Does that mean that in theory, a block could have arrived between the call toCreateNewBlockandIncrementExtraNonce, thus makingIncrementExtraNoncewrite out a wrong height into the coinbase? I realise that this is only for regtest mode and thus a non-issue, but it seems "wrong" nevertheless.The code for
getblocktemplate, on the other hand, lockscs_mainover most of its length. Because of this, the usage ofpindexPrevNew(with a comment "to avoid races") seems unnecessary. Or do I miss anything here?None of these is an issue I would consider "critical" - but both seem a bit inconsistent to me. Unless I miss some details here, the code in its current form seems, at least, confusing about how locking "should" be done.