Explore ManualResetEvent waiter storage and state fast paths
- Dominant language
- Rust
- Stars
- 269
- Forks
- 38
- Avg merge
- 16h 44m
- Merged PRs (30d)
- 102
Description
## Background
PR #243 added `ManualResetEvent` with a mutex-protected boolean state and `WaitList`. Its approval review left the internal representation as a follow-up exploration: the ideas may improve the implementation, but keeping the current design is valid if the alternatives do not preserve its contracts or reduce overall cost.
## Questions to explore
1. Can `ManualResetEvent` replace `WaitList` and its per-waiter `notified` state with `WaitSet` while preserving the rule that every wait registered before `set` remains committed even if `reset` happens before its next poll?
2. Can `is_set` and the already-set wait path use an atomic boolean, or another compact atomic state, instead of acquiring the state mutex on every observation?
## Requirements
- preserve the public API and the set/reset, first-poll registration, cancellation, and memory-publication contracts introduced by #243;
- prevent lost wake-ups across concurrent state checks, waiter registration, `set`, and `reset`;
- keep waker clone, drop, and wake callbacks outside internal locks;
- account for reentrant callbacks and a rapid `set` followed by `reset`;
- compare complexity and benchmark results with the current implementation, including `is_set`, already-set waits, pending registration/cancellation, set/reset reuse, and fan-out;
- prefer the current implementation if an alternative only moves complexity or lacks a meaningful workload benefit.
Follow-up to #221 and #243. The originating approval review is [here](https://github.com/apache/asyncband/pull/243#pullrequestreview-5061484283).
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing PR #243 and follow-up #221, then inspect the current ManualResetEvent, WaitList, and WaitSet implementation. Compare the alternatives against the stated registration, cancellation, wake-up, callback, and memory-publication contracts, including the required benchmark cases. Done means documenting whether an alternative provides a meaningful benefit or retaining the current implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100