setgenerate creates multiple blocks in -regtest mode #3294

pull gavinandresen wants to merge 1 commits into bitcoin:master from gavinandresen:regtest_setgenerate changing 5 files +45 −11

gavinandresen commented at 4:24 AM on November 21, 2013: contributor
I'm writing some wallet regression tests using -regtest mode, and need to generate an initial multi-hundred-block chain. Repeatedly calling setgenerate to generate one block is slow and doesn't work properly, because block creation happens asynchronously.

This adds two features to setgenerate in -regtest mode:
1. Instead of being interpreted as number of threads to start, the third argument is the number of blocks to generate.
2. setgenerate will not return until the block creation threads have created the requested number of blocks.

in src/rpcmining.cpp:None in 1b162db41f outdated

 132 | @@ -133,6 +133,7 @@ Value setgenerate(const Array& params, bool fHelp)
 133 |              "\nArguments:\n"
 134 |              "1. generate         (boolean, required) Set to true to turn on generation, off to turn off.\n"
 135 |              "2. genproclimit     (numeric, optional) Set the processor limit for when generation is on. Can be -1 for unlimited.\n"
 136 | +            "                    Note: in -regtest mode, genproclimit controls how many blocks are generated immediately.\n"

Diapolo commented at 3:55 PM on November 21, 2013:

You should also add these hint to the help-message in init.cpp (if -genproclimit is in there).

in src/rpcmining.cpp:None in 1b162db41f outdated

 148 | @@ -148,17 +149,49 @@ Value setgenerate(const Array& params, bool fHelp)
 149 |      if (params.size() > 0)
 150 |          fGenerate = params[0].get_bool();
 151 |  
 152 | +    int nGenProcLimit = 1;

Diapolo commented at 3:58 PM on November 21, 2013:

Why init to 1, if our default seems to be -1?

gavinandresen commented at 11:39 PM on November 21, 2013: contributor

@Diapolo: good catch on the -1. init.cpp doesn't mention gen/genproclimit, since generating blocks is a developer-only feature (we don't want people thinking they can successfully CPU mine on the main network).

setgenerate creates multiple blocks in -regtest mode

I'm writing some wallet regression tests using -regtest mode, and
need to generate an initial multi-hundred-block chain. Repeatedly
calling setgenerate to generate one block is slow and doesn't
work properly, because block creation happens asynchronously.

This adds two features to setgenerate in -regtest mode:

1) Instead of being interpreted as number of threads to start, the
third argument is the number of blocks to generate.

2) setgenerate will not return until the block creation threads
have created the requested number of blocks.

c8b74258ba

BitcoinPullTester commented at 12:38 AM on November 22, 2013: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/c8b74258bad399d39262ed11b892a729196cb297 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
sipa commented at 12:31 PM on November 22, 2013: member

I think overloading the meaning of that setgenerate argument for regtest is ugly.

Can't we move that functionality to an additional argument? Ideally there are as few explicit checks for what network we're working on in the code itself.
gavinandresen commented at 12:17 AM on November 23, 2013: contributor

@sipa: number of threads is ignored in regtest mode already (one thread is used, and it exits as soon as a block is found).

If you like, you can think of it as "Start N threads, and exit each as soon as a block is found." That isn't actually how it is implemented, of course (blocks are found so quickly the N threads would stomp on each other's blocks)...

I'm normally sympathetic to "makes RPC ugly" arguments, but since setgenerate is ONLY for developers/testing/debugging I think ugly is just fine here.
laanwj commented at 6:42 AM on November 23, 2013: member

Right, I was about to make the same comment about overloading arguments when I saw the code, another thing that I noticed is that setgenerate (regtest) and setgenerate (normal) are almost completely distinct and it may make sense to split functions instead of check the mode everywhere.

...but it's only setgenerate so meh.
laanwj referenced this in commit 4c3e24644d on Nov 25, 2013
laanwj merged this on Nov 25, 2013
laanwj closed this on Nov 25, 2013
gavinandresen deleted the branch on Mar 13, 2014
Bushstar referenced this in commit 141861ebae on Apr 8, 2020
DrahtBot locked this on Sep 8, 2021

Contributors

Linked (view graph)

#3295 Wallet RPC calls integration test