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.