90d4d89 scripted-diff: Use the C++11 keyword nullptr to denote the pointer literal instead of the macro NULL (practicalswift)
Pull request description:
Since C++11 the macro `NULL` may be:
* an integer literal with value zero, or
* a prvalue of type `std::nullptr_t`
By using the C++11 keyword `nullptr` we are guaranteed a prvalue of type `std::nullptr_t`.
For a more thorough discussion, see "A name for the null pointer: nullptr" (Sutter &
Stroustrup), http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf
With this patch applied there are no `NULL` macro usages left in the repo:
```
$ git grep NULL -- "*.cpp" "*.h" | egrep -v '(/univalue/|/secp256k1/|/leveldb/|_NULL|NULLDUMMY|torcontrol.*NULL|NULL cert)' | wc -l
0
```
The road towards `nullptr` (C++11) is split into two PRs:
* `NULL` → `nullptr` is handled in PR #10483 (scripted, this PR)
* `0` → `nullptr` is handled in PR #10645 (manual)
Tree-SHA512: 3c395d66f2ad724a8e6fed74b93634de8bfc0c0eafac94e64e5194c939499fefd6e68f047de3083ad0b4eff37df9a8a3a76349aa17d55eabbd8e0412f140a297
This resolves a possible-assert-on-shutdown race introduced in
1f668b6468 when early shutdown
occurs.
Previously this was not done to avoid any cases where the
threadGroup might not exit due to a blocking thread, but at this
point the threadGroup isn't used all that much, plus Qt already
does this, and its good to keep their init/shutdown consistent.
For those curious, the threadGroup is only used in a few places:
* Its used to run the CCheckQueues in script validation, but these
use the boost mutex/condition variable primitives, so they
respect the interrupt pretty trivially.
* Its used for the import thread, which should exit rather quickly
as mostly it just calls LoadExternalBlockFile, which has an
interruption_point right before each block loaded.
* Its used in the scheduler thread, which is only used for:
* validationinterface has an effectively-dummy reference to it.
* wallet compaction, which should not last long
* addr/banlist dumping from CConnman, which should also be fast
Alternative to #10818, alternative solution to #10815.
After this change: All the AppInit steps before and inclusive
AppInitLockDataDirectory must not have Shutdown() called in case of
failure. Only when AppInitMain fails, Shutdown should be called.
Changes the GUI and bitcoind code to consistently do this.
The current message is not helpful. Hardly anyone even remembers that
bitcoind used to be a cli utility, let alone new users. Print what the
actual problem is.
deec83f init: Get rid of fServer flag (Wladimir J. van der Laan)
16ca0bf init: Try to aquire datadir lock before and after daemonization (Wladimir J. van der Laan)
0cc8b6b init: Split up AppInit2 into multiple phases (Wladimir J. van der Laan)
- `--help`, `--version` etc should exit with `0` i.e. no error ("not enough args" case should still trigger an error)
- error reading config file should exit with `1`
Slightly refactor AppInitRPC/AppInitRawTx to return standard exit codes (EXIT_FAILURE/EXIT_SUCCESS) or CONTINUE_EXECUTION (-1)
Simplified version of #8278. Assumes that every OS that (a) is supported
by Bitcoin Core (b) supports daemonization has the `daemon()` function
in its C library.
- Removes the fallback path for operating systems that support
daemonization but not `daemon()`. This prevents never-exercised code from
ending up in the repository (see discussion here:
https://github.com/bitcoin/bitcoin/pull/8278#issuecomment-242704745).
- Removes the windows-specific path. Windows doesn't support `daemon()`,
so it don't support daemonization there, automatically.
Original code by Matthew King, adapted by Wladimir van der Laan.
- *Replace usage of boost::asio with [libevent2](http://libevent.org/)*.
boost::asio is not part of C++11, so unlike other boost there is no
forwards-compatibility reason to stick with it. Together with #4738 (convert
json_spirit to UniValue), this rids Bitcoin Core of the worst offenders with
regard to compile-time slowness.
- *Replace spit-and-duct-tape http server with evhttp*. Front-end http handling
is handled by libevent, a work queue (with configurable depth and parallelism)
is used to handle application requests.
- *Wrap HTTP request in C++ class*; this makes the application code mostly
HTTP-server-neutral
- *Refactor RPC to move all http-specific code to a separate file*.
Theoreticaly this can allow building without HTTP server but with another RPC
backend, e.g. Qt's debug console (currently not implemented) or future RPC
mechanisms people may want to use.
- *HTTP dispatch mechanism*; services (e.g., RPC, REST) register which URL
paths they want to handle.
By using a proven, high-performance asynchronous networking library (also used
by Tor) and HTTP server, problems such as #5674, #5655, #344 should be avoided.
What works? bitcoind, bitcoin-cli, bitcoin-qt. Unit tests and RPC/REST tests
pass. The aim for now is everything but SSL support.
Configuration options:
- `-rpcthreads`: repurposed as "number of work handler threads". Still
defaults to 4.
- `-rpcworkqueue`: maximum depth of work queue. When this is reached, new
requests will return a 500 Internal Error.
- `-rpctimeout`: inactivity time, in seconds, after which to disconnect a
client.
- `-debug=http`: low-level http activity logging
The main thread spends time waiting for the DetectShutdownThread.
So why not just run this waiting loop function in the main thread?
One thread-stack less saves 4MB of virtual memory on 32-bit, and 8MB on
64-bit.
Always make a pid file, not only when `-daemon` specified.
This is useful for troubleshooting, for attaching debuggers and loggers
and such.
- Write the pid file only after the datadir lock was acquired
- Don't create or remove a pid file on WIN32, and also don't show the option
MeshCollider