Go 1.14 added runtime support for handling the windows CTRL_CLOSE_EVENT,
CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT events by adding a definition
for syscall.SIGTERM to windows and converting the events to that signal.
It also added definitions for other common signals, including SIGHUP,
and treats them as NOOPs on windows.
Consequently, this modifies the logic that deals with conditionally
handling SIGTERM and SIGHUP to handle them for windows as well as all
unix-like operating systems, including newer ones that are supported by
Go since the code was originally written.
Although the additional signals could probably just be added
unconditionally without too much issue now due to the runtime adding
stubs to all operating systems the project officially supports, it is
safer to be explicit when dealing with syscall definitions since there
is no guarantee that they will exist for newly-added operating systems.
Upgrade the dcrwallet dependency to pick up the new version of
txrules.StakePoolTicketFee which considers the status of DCP0012 in its
fee calculation.
Don't log errors returned by server.Shutdown. They are exceedingly
unlikely, and there is nothing which can be done about them.
Moving the "Listening on..." log closer to where the server is actually
started reduces the chance of confusion. Also, logging the parsed
listener.Addr() string instead of the provided config string provides
extra debugging detail.
The vspd Run func is now blocking and returns when its provided context
is cancelled. This means it is invoked/canceled in the same way as the
webapi Run func.
webapi is now created in the main run func rather than within vspd,
further decoupling these components.
The server will shutdown cleanly even if the passed context is already
canceled, so there is no need to pass a new context and blindly guess at
how long the server may need to stop.
Exporting this struct is a step towards breaking up the Start func into
a New func and Run func, enabling calling code to use:
api := webapi.New()
api.Run()
WebAPI is a more suitable name than server because it matches the
package name, and also it helps to distinguish WebAPI from the HTTP
server it uses internally (ie. webapi.server rather than server.server).
It's generally good practice to first create everything that can fail
and then create the final instance at once with the results versus doing
it piecemeal.
Piecemeal creation is typically more error prone and, while not a huge
concern here, it also ends up needlessly creating objects that are just
thrown away in the event of a later error.
Storing references to the database/dcrd/dcrwallet clients inside the
cache struct means they don't need to be passed in every time the cache
is updated.
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.
vspd runs some tasks on startup - database consistency checks, catching
up with missed blocks, etc. If a shutdown is requested while these tasks
are running, vspd should stop immediately rather than continuing to
start the web API server and other background tasks.
The more verbose name was helpful in the past when some code was
handling more than one context, however that is no longer the case due
to refactoring so reverting to the more concise name makes sense.
Using a single select loop for background tasks removes a lot of
duplicated boilerplate code and helps to simplify shutdown logic. This
does reduce the amount of things which can run in parallel, but that
isn't of concern for vspd. The web server still runs in its own
goroutine so its responsiveness won't be affected.
