59f5844381
This commit combines the `apply_mutex` and `read_mutex` into a single `mutex_` var. This new `mutex_` var is a `shared_mutex`, and most operations only need to lock it with a `shared_lock`. The only exception is `applyMutex`, which may need a `unique_lock`. One consequence of removing the `apply_mutex` is more than one `applyMutex` function can run at the same time. To help reduce lock contention that a `unique_lock` would cause, checks that only require reading data are run a `shared_lock` (call these the "prewriteChecks"), then the lock is released, then a `unique_lock` is acquired. Since a currently running `applyManifest` may write data between the time a `shared_lock` is released and the `write_lock` is acquired, the "prewriteChecks" need to be rerun. Duplicating this work isn't ideal, but the "prewirteChecks" are relatively inexpensive. A couple of other designs were considered. We could restrict more than one `applyMutex` function from running concurrently - either with a `applyMutex` or my setting the max number of manifest jobs on the job queue to one. The biggest issue with this is if any other function ever adds a write lock for any reason, `applyManifest` would not be broken - data could be written between the release of the `shared_lock` and the acquisition of the `unique_lock`. Note: it is tempting to solve this problem by not releasing the `shared_mutex` and simply upgrading the lock. In the presence of concurrently running `applyManifest` functions, this will deadlock (both function need to wait for the other to release their read locks before they can acquire a write lock).
rippled Source
Some of these directories come from entire outside repositories brought in
using [git-subtree][]. This means that the source files are inserted directly
into the rippled repository. They can be edited and committed just as if they
were normal files.
[git-subtree]: https://github.com/apenwarr/git-subtree
If you create a commit that contains files both from a subtree, and from the
rippled source tree, please use care when designing the commit message, since
it will appear in the subtree's individual repository when the changes are
pushed back to the upstream. Better yet, do not mix files from subtrees and
ripple in the same commit at all.
Source folders:
| Folder | Upstream Repo | Description |
|---|---|---|
beast |
N/A | legacy utility code that was formerly associated with boost::beast |
ed25519-donna |
https://github.com/floodyberry/ed25519-donna | Ed25519 digital signatures |
ripple |
N/A | Core source code for rippled |
secp256k1 |
https://github.com/bitcoin-core/secp256k1 | ECDSA digital signatures using the secp256k1 curve |
test |
N/A | Unit tests for rippled |
The following dependencies are downloaded and built using ExternalProject (or FetchContent, where possible). Refer to CMakeLists.txt file for details about how these sources are built :
| Name | Upstream Repo | Description |
|---|---|---|
lz4 |
https://github.com/lz4/lz4 | LZ4 lossless compression algorithm |
nudb |
https://github.com/vinniefalco/NuDB | Constant-time insert-only key/value database for SSD drives (Less memory usage than RocksDB.) |
snappy |
https://github.com/google/snappy | "Snappy" lossless compression algorithm. |
soci |
https://github.com/SOCI/soci | Abstraction layer for database access. |
sqlite |
https://www.sqlite.org/src | An embedded database engine that writes to simple files. |
rocksdb |
https://github.com/facebook/rocksdb | Fast key/value database. (Supports rotational disks better than NuDB.) |
protobuf |
https://github.com/google/protobuf | Protocol buffer data interchange format. Only downloaded/built if a suitable version is not found by find_package, or if the local_protobuf option is explicitly set |