This significantly reworks the CPU miner to make use of the background
block template generator that was introduced in the previous release as
well as to convert its lifecycle to use the expected pattern for running
subsystems based on contexts.
The switch to using the background block template generator provides all
the benefits it offers to miners such as:
- Intelligent vote propagation handling
- Improved handling of chain reorganizations necessary when the current
tip is unable to obtain enough votes
- Current state synchronization
- Near elimination of stale templates when new blocks and votes are received
This is particularly important in testing scenarios, such as when using
the simulation network, since the difficulty is so low that the code
this is replacing is often able to mine blocks so fast it ends up mining
multiple alternative blocks while waiting for the votes to show up which
makes testing with it more difficult.
This is no longer an issue when requesting template updates since the
background block template generator has logic to provide the votes a
chance to arrive before building and notifying the template.
Another modification this makes is to also make use of template
notifications when mining blocks mined via the discrete mining mode and
to only count blocks if they successfully extend the main chain. This
also significantly helps in testing scenarios since it means the testing
code and/or testers using the simulation test network can rely on the
requested number of blocks actually being added to the main chain even
if more need to be generated to make that happen.
Along similar lines, one area this change does not address, but does
pave the way to support and would be useful in the future for the
simulation test network is to add some additional logic to provide
ticket purchases a chance to arrive when prior to stake validation
height, since that is another area that often complicates testing.
In terms of the lifecycle changes, this replaces the Start, Stop, and
Wait methods with a single method named Run and arranges for it to block
until the provided context is cancelled. This is more flexible for the
caller since it can easily turn blocking code into async code while the
reverse is not true.
The new Run method waits for all goroutines that it starts to shutdown
before returning to help ensure an orderly shutdown.
In addition, the semantics of Run are different from Start/Stop in that
the Start method launched the default number of mining worker goroutines
whereas Run only starts the CPU miner with the main infrastructure
goroutines and zero workers, meaning it will be idle until explicitly
requested to mine by the caller setting the number of workers to use.
Since there are exported methods that send messages to the CPU miner
infrastructure goroutines via a channel and those goroutines are stopped
during the shutdown process, all sends select across both the channel in
question as well as a quit channel which is closed when the context is
canceled. This ensures callers can't end up blocking on send to a
goroutine that is no longer running without needing additional mutexes.
As part of the conversion, it improves a lot of the comments to better
describe the expected behavior and further integrates the context to
support cancellation where it previously was not supported.
Finally, all callers are updated to use the new API and the server is
modified to take advantage of the new lifecycle semantics by taking
ownership of the CPU miner code directly in its Run method where it more
logically makes sense and only creating the template generate and CPU
miner infrastructure if needed based on the configuration options.
a6feca22cd
