Define and enforce `CancellationToken` conventions

未关闭
  • 哪里不对？
#614 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
冷清
技术栈
rust
领域
distributed-systems

调研方向

首先阅读 .claude/skills/rust-style/SKILL.md，并检查 tracker、validatorapi、sse 和 prioritiser 中现有的 CancellationToken 使用情况。将 privkeylock.rs 和 wire.rs 中链接的 drop_guard 位置与孤立 token 的情况进行比较，然后记录相关约定并使标记的位置保持一致。满足验收标准即视为完成，包括为任何有意独立的孤立 token 添加注释。

由索引模型根据 Issue 内容生成。

描述

documentation rust

Summary

CancellationToken is the most pervasive abstraction in the workspace (550 lines across 74 files) with no written rules, and usage has drifted:

  • clone() vs child_token() is ~141:52. A clone shares the same scope, so any holder calling .cancel() tears down the whole tree; children are the right default for subordinate tasks. Disciplined child_token use exists only in dkg; large subsystems (tracker: 19 CT lines, validatorapi: 25, sse: 15) use zero.
  • drop_guard() appears exactly twice (privkeylock.rs#L123, wire.rs#L1140). Everywhere else an early-returning task leaves siblings running with no signal.
  • Orphan tokens with no parent link (cancel never propagates from the caller): prioritiser's quit, deadliner's internal token, dkg's lock_ct.
  • Three vocabularies coexist: select! { _ = ct.cancelled() => ... } (~41 sites), ct.run_until_cancelled(fut) (24 sites, nearly all in one file), and the third-party cancellation crate's callback API in the QBFT core (goes away with draft 05a).
  • Naming (ct, cancel, cancellation, token, quit) and by-value vs &CancellationToken passing are unstandardized, forcing gratuitous clones at boundaries.

Proposed change

Update the current set of conventions: when to child_token vs clone, when a task owns a DropGuard, one preferred waiting idiom, parameter naming and passing. Then sweep the flagged sites — in particular giving subordinate tasks child tokens and auditing the orphan tokens for missed shutdown propagation.

Acceptance

Documented rules plus a pass over tracker/validatorapi/sse/prioritiser aligning them; no orphan token without a comment explaining its independence.

主要语言
Rust
星标
8
派生
5
平均合并
3 天 1 小时
30 天内合并 PR
2

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

NethermindEth/pluto 的其他 Issue

查看 NethermindEth/pluto 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。