Update default number of RPC threads to 16 (#31215) and remove reference to very old version of bitcoin core.
Let me know if you notice other mismatches with current defaults.
Update default number of RPC threads to 16 (#31215) and remove reference to very old version of bitcoin core.
Let me know if you notice other mismatches with current defaults.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31985.
See the guideline for information on the review process.
Type | Reviewers |
---|---|
ACK | brunoerg, TheCharlatan, vasild, achow101 |
Stale ACK | dergoegge |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Update default number of RPC threads to 16 (#31215) and remove reference
to very old version of bitcoin core.
DEFAULT_HTTP_THREADS
constant.
Let me know if you notice other mismatches with current defaults.
In this file “The minimum value for -dbcache
is 4.” However it’s entirely possible to run bitcoind with -dbcache=1
. Maybe that line can just be dropped?
In this file “The minimum value for -dbcache is 4.” However it’s entirely possible to run bitcoind with -dbcache=1. Maybe that line can just be dropped?
Could be removed if it’s not longer correct, but to be clear: 4 here was meant here as the minimum effective value, not the minimum value that would be accepted as command line argument.
Edit, seems that still holds:
0//! min. -dbcache (bytes)
1static constexpr size_t MIN_DB_CACHE{4_MiB};
not the minimum value that would be accepted as command line argument.
Should we make this function like maxmempool, which will fail to accept a value lower than the minimim (5)? Seems we are somewhat inconsistent in our handling of these.
Should we make this function like maxmempool, which will fail to accept a value lower than the minimim (5)? Seems we are somewhat inconsistent in our handling of these.
Yes, probably. It’s pretty much always better for user communication to fail for wrong values than to silently interpret them as something else.
(although we have to be careful around the GUI to not create a user lock-out situation like bitcoin-core/gui#843 )