Background
PR #245 makes WaitSet accept owned wakers so cloning, dropping, and waking user-provided wakers stay outside primitive state locks. Its callers now fall into three workload-driven polling shapes:
- monotonic state with a cheap lock-free probe can probe, clone, lock, and recheck;
- park-once primitives can clone before taking their state lock;
- primitives with a hot ready or buffered path can check under the lock, clone outside it only when needed, then lock and recheck.
Completion currently uses the third shape even though its Pending to Completed or Abandoned transition is monotonic. That preserves a cheap ready path, but makes its pending registration loop harder to understand.
Goal
Evaluate whether Completion can use a simpler monotonic-state design, for example an atomic status alongside the existing OnceLock<T> and mutex-protected WaitSet. A successful design should retain a lock-free completed or abandoned probe and need only one waiter-lock acquisition on the common pending path, without executing RawWaker clone, drop, or wake callbacks under that lock.
Requirements
- preserve the current public API, abandonment semantics, cancellation safety, and borrowed result;
- give a complete Acquire/Release argument for publishing the
OnceLock value and abandonment;
- preserve safety under reentrant or panicking
RawWaker clone, drop, and wake callbacks;
- compare the candidate with
main using ready wait, pending registration and cancellation, single notification, and fan-out benchmarks;
- prefer the current implementation if a candidate does not lower the overall reasoning cost without a meaningful performance regression.
This should not introduce a generic polling-policy abstraction shared by unrelated primitives merely to hide their different load profiles.
Background
PR #245 makes
WaitSetaccept owned wakers so cloning, dropping, and waking user-provided wakers stay outside primitive state locks. Its callers now fall into three workload-driven polling shapes:Completioncurrently uses the third shape even though itsPendingtoCompletedorAbandonedtransition is monotonic. That preserves a cheap ready path, but makes its pending registration loop harder to understand.Goal
Evaluate whether
Completioncan use a simpler monotonic-state design, for example an atomic status alongside the existingOnceLock<T>and mutex-protectedWaitSet. A successful design should retain a lock-free completed or abandoned probe and need only one waiter-lock acquisition on the common pending path, without executingRawWakerclone, drop, or wake callbacks under that lock.Requirements
OnceLockvalue and abandonment;RawWakerclone, drop, and wake callbacks;mainusing ready wait, pending registration and cancellation, single notification, and fan-out benchmarks;This should not introduce a generic polling-policy abstraction shared by unrelated primitives merely to hide their different load profiles.