Research lightweight handling of panicking wakers
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start by reading issues #341 and #335 to understand the current non-panicking contract and the complexity that was removed. Compare the linked Tokio, thingbuf, event-listener, embassy-sync, and asupersync approaches, then produce a small prototype with targeted validation. Done means an evidence-backed proposal or documented conclusion that preserves ownership and unwind safety without adding dependencies or complicating the normal path.
由索引模型根据 Issue 内容生成。
描述
Motivation
Follow-up to #341, with the earlier discussion in #335. Asyncband currently expects executor waker operations to be non-panicking and does not promise recovery from panicking waker operations. Removing the previous recovery machinery made notification and permit-distribution paths substantially easier to follow.
A wake callback can still panic after a batch of waiters has been detached, interrupting the remaining notifications. Investigate whether we can attempt those remaining wakes with a small, clear implementation, without restoring the complexity removed in #341.
Research questions
- Which real-world executor or custom-waker scenarios benefit from recovery, and what behavior should callers observe after catching the panic?
- Can an ownership or RAII-based approach provide useful recovery? Distinguish cleaning up remaining wakers from actually waking them, and account for a later wake also panicking or cleanup running during an existing unwind.
- What state must be committed before invoking callbacks, especially for permit distribution and cancellation handoff?
- Where should the recovery boundary be? Focus on
wakeandwake_by_ref; assesscloneanddropwhere they affect the proposed approach, rather than assuming that every waker operation needs a general recovery framework. - What are the costs in code complexity, allocation, and the normal notification path?
Existing examples
The initial source review found several different policies rather than one ecosystem-wide convention:
- Tokio 1.53.1 WakeList uses a drop guard to destroy remaining wakers after a wake panic; it does not attempt the remaining wakes. Its internal AtomicWaker separately restores registration state after a clone panic.
- thingbuf 0.1.6 WaitCell follows Tokio's registration-recovery strategy, while its batch queue notifications directly invoke callbacks.
- event-listener 5.4.2 directly invokes wake callbacks in its notification loop, without per-callback panic isolation. async-lock, async-channel, and async-broadcast build on this notification mechanism.
- embassy-sync 0.8.0 MultiWakerRegistration clears the stored length before waking to preserve memory safety during unwinding; a panic stops the loop and can leak the remaining wakers.
- asupersync 0.5.0 Notify catches each wake panic, retains the first payload, attempts the remaining wakes, and then resumes the first panic. This is a concrete comparison point for the stronger behavior and its implementation cost.
Desired outcome
An evidence-backed proposal with a small prototype and targeted validation, or a documented conclusion explaining why the available approaches do not justify their complexity. Keep callbacks and replaced or cancelled waker destruction outside primitive locks, preserve basic ownership and unwind safety, introduce no new dependencies, and keep the normal path simple.
A successful approach is intended to be a non-breaking robustness improvement under the contract established by #341. Broader guarantees for arbitrary panicking waker operations should be justified separately.
- 主要语言
- Rust
- 星标
- 283
- 派生
- 49
- 平均合并
- 10 小时 58 分钟
- 30 天内合并 PR
- 37
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
apache/asyncband 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 57/100
维护者通常 1 天内回复
-
Tracking Issue to Release 0.7.4可能已有人在做 @QwQBiG 于 9 天前认领。 未关闭
apache/asyncband#369 · 2 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Investigate unsound mapped RwLock write guard downgrading可能已有人在做 @orthur2 于 11 天前认领。 未关闭
难度 5/5 一周以上 新手友好度 25/100
apache/asyncband#362 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 55/100
apache/asyncband#360 · 3 条评论 ·
维护者通常 1 天内回复
-
enhancement good first issue help wanted
难度 5/5 一周以上 新手友好度 35/100
apache/asyncband#324 · 1 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
good first issue help wanted r-feature
难度 2/5 1-3 小时 新手友好度 82/100
servo/rust-smallvec#792 ·
维护者通常 1 天内回复
-
A-Unicode C-bug P-low
难度 2/5 1-3 小时 新手友好度 70/100
rust-lang/rustfmt#7210 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 1/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复
-
area:sim good first issue kind:feature
难度 2/5 1-3 小时 新手友好度 87/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 66/100
bitcoindevkit/bdk#2432 ·
维护者通常 3 天内回复