4fcb550aa6
The components are accessed by a lock on application state. When some command calls block_on to enter an async context, it obtained a write lock on the entire application state. This meant that if the application state were accessed later in an async context, a deadlock would occur. Instead the TokioComponent holds an Option<Runtime> now, so that before calling block_on, the caller can .take() the runtime and release the lock. Since we only ever enter an async context once, it's not a problem that the component is then missing its runtime, as once we are inside of a task we can access the runtime. |
||
---|---|---|
.github/workflows | ||
design | ||
zebra-chain | ||
zebra-client | ||
zebra-consensus | ||
zebra-network | ||
zebra-rpc | ||
zebra-script | ||
zebra-storage | ||
zebrad | ||
.gitignore | ||
.rustfmt.toml | ||
Cargo.lock | ||
Cargo.toml | ||
Dockerfile | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
README.md | ||
cloudbuild.yaml |
README.md
zebra 🦓
Hello! I am Zebra, an ongoing Rust implementation of a Zcash node.
License
Zebra is distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT.