Skip to content
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

Prep for dual network support #62

Merged
merged 6 commits into from
Oct 13, 2023
Merged

Conversation

jholdstock
Copy link
Member

I have a working diff to run a single instance of dcrseeder on mainnet and testnet simultaneously (#14). The commit which adds dual network support is reasonably large on its own, so to ease reviewing I have opened this preliminary PR which is some the necessary prep work.

Copy link
Member

@davecgh davecgh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good overall. I always appreciate nice separation of commits to help review.

In addition to a few inline things pointed out, the first commit message says "in future" versus "in the future".

http.go Outdated Show resolved Hide resolved
decred.go Outdated Show resolved Hide resolved
The new crawler struct contains its own reference to an address manager
instance rather than using the global reference. This opens the
possibility of multiple crawlers using different address managers in
the future.
The web server only needs a reference to an address manager once (during
initialization) so it can be passed as a parameter and the global
var can be removed.
The new server struct is initialized and run as two distinct steps. Any
errors during initialization (eg. port already in use) will cause
dcrseeder to exit.

The run function is blocking and returns when the provided context is
canceled.
Rather than using the default global logger provided by the log package,
initialize a logger with a prefix to indicate the network dcrseeder is
running on ("[mainnet]" or "[testnet]"). Pass that logger around as a
parameter and use it in all subsystems.
Config validation/prep was split between the loadConfig func and the
main func. This consolidates it into loadConfig.
Any tasks deferred in the main func will not execute if os.Exit is
called. Moving application logic down into a new func which is called by
main works around this limitation.
@davecgh davecgh merged commit 2362f63 into decred:master Oct 13, 2023
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants