Research lightweight handling of panicking wakers

[tisonkun]

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 wake and wake_by_ref; assess clone and drop where 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.

[tisonkun]

fyi @BewareMyPower @QwQBiG

[tisonkun]

To be clear, we may finally end up with doing nothing and keep the current behavior.

[BewareMyPower]

I was also wondering in which cases should the caller handle the case when a waker panics when I was working on #335. It looks more like a pre-mature optimization.

asupersync 0.5.0 Notify catches each wake panic,

The first refactoring commit in #335 is this solution, I ran a benchmark locally (the 1st commit catches each panic):

size     0a551eff    0f468315   last vs first
---------------------------------------------
1        20.29 ns    13.73 ns   -32.3%
2        22.74 ns    16.83 ns   -26.0%
32      213.67 ns   168.13 ns   -21.3%
256      1.671 us    1.213 us   -27.4%

The overhead is significant.

[QwQBiG]

I tested a continue-waking batch prototype. Releasing 65 permits to 65 waiters still stops after the first batch of 32 when the panic propagates. Finishing the wakes doesn't finish permit distribution.

I'd keep #341's contract unless we find a concrete use case for stronger recovery. :3

One smaller question: an inline wake panic can leave the remaining inline wakers undropped. Would cleanup-only handling be worth a separate change, without promising recovery?

[tisonkun]

One smaller question: an inline wake panic can leave the remaining inline wakers undropped. Would cleanup-only handling be worth a separate change, without promising recovery?

I think the question here is whether Waker::wake would panic. If we assert not, as most current runtime does, we need to do nothing because it won't panic; if it can panic, we should handle it as a whole (no resource leak, no forgotten waker).

[QwQBiG]

Makes sense. Let's keep #341 as-is for now.

We can revisit this if a concrete use case comes up. :3

[tisonkun]

OK. Then I'd close this issue as won't do for now.

One can revive it if he/she finds any lightweight solution to handle panicking wakers well.

BTW @QwQBiG I'd expect you may go through our release process to cut a new release. Perhaps after the National Day holiday. And @orthur2 and I can help you walk it through if you need any help.

[QwQBiG]

Thanks, @tisonkun ! Agreed on closing this issue for now.

I'd be happy to learn the release process and work on the next release with guidance from you and @orthur2. I'll read through the release documentation first and ask if anything is unclear.

Thanks for the opportunity! :3