Unify lock usage; prefer actor ownership over shared locks
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- rust
调研方向
首先阅读 crates/consensus/src/qbft/component.rs、crates/core/src/parsigdb/memory.rs、crates/dkg/src/sync/client.rs、crates/p2p/src/p2p_context.rs 和 crates/eth2util/src/network.rs 中列出的锁位置，然后查看现有的样式文档。当锁所有权规则已记录，并且标记的位置已完成转换，或已注释说明其当前锁形式为何合适时，即视为完成。
由索引模型根据 Issue 内容生成。
描述
Summary
Lock usage is split with no documented rule: std::sync::{Mutex,RwLock} in 41 files, tokio::sync in 22 (parking_lot is not a dependency — the backlog can drop that option). 52 call sites deal with poison (PoisonError::into_inner / expect("... poisoned")).
Several locks guard data with a single logical owner, where a channel/actor removes the lock entirely:
expired_rx: Mutex<Option<mpsc::Receiver<Duty>>>— a mutex wrapping a channel receiver just to make it&self-takeable, the textbook symptom.instances: Arc<Mutex<HashMap<Duty, Arc<InstanceIo<Msg>>>>>— per-duty registry with one owner.parsigdb'sArc<tokio::sync::Mutex<MemDBInner>>— already half-actor (it has an mpsc trim loop).dkg/sync/client.rs#L40-L42mixes astd::sync::RwLockwithwatch::Senders in the same struct;dkg'sMutex + Notifypairs are hand-rolled actors.P2PContext::peer_storereturnsRwLockReadGuard/WriteGuardfrom public methods, leaking guards across the API boundary.SUPPORTED_NETWORKS: LazyLock<RwLock<Vec<Network>>>— a mutable process-global registry.
Proposed change
This is a design task first: pick a general rule (the standard one works: std::sync for short, non-await-crossing critical sections; tokio::sync when a guard is held across .await; actor + channels when data has one logical owner), document it and enforce it. Later, convert the listed actor candidates. Finally:
- Stop returning guards from
P2PContext - Make
SUPPORTED_NETWORKSimmutable-after-init or explicitly injected.
Acceptance
A written rule in the style docs, and the flagged sites either converted or annotated with why the lock is the right shape.
- 主要语言
- Rust
- 星标
- 8
- 派生
- 5
- 平均合并
- 4 天 18 小时
- 30 天内合并 PR
- 4
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
NethermindEth/pluto 的其他 Issue
-
难度 4/5 3-5 天 新手友好度 52/100
NethermindEth/pluto#719 ·
-
enhancement rust
难度 4/5 3-5 天 新手友好度 45/100
NethermindEth/pluto#640 ·
-
rust
难度 5/5 一周以上 新手友好度 45/100
NethermindEth/pluto#638 · 1 条评论 ·
-
enhancement rust
难度 5/5 一周以上 新手友好度 35/100
NethermindEth/pluto#635 ·
-
Improve `alpha test peers`: match Charon's probes; reduce timeouts可能已有人在做 @varex83agent 于 24 天前认领。 未关闭bug track:orchestration-cli
难度 5/5 一周以上 新手友好度 28/100
NethermindEth/pluto#632 ·
查看 NethermindEth/pluto 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
manuscript-lang/manuscript#1364 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
fable-compiler/Fable#5157 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 73/100
维护者通常 1 天内回复
-
C-bug needs-triage O-UEFI T-libs
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
移动端宽屏适配未关闭
难度 2/5 1-3 小时 新手友好度 64/100
维护者通常 1 天内回复