apache/asyncband

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

An object pool needs to decide whether a resource can be reused, while applications may need to understand why it was rejected. Asyncband currently checks idle objects during checkout, discards is_recyclable errors, and retries. Returning an object does not run this check. We would like to explore: Typical uses for recycling diagnostics, such as investigating failed health checks or resets, and whether an optional error sink would help. When checks belong at checkout, before return, or in caller code, including discarding an object already known to be broken. Whether a separate synchronous check has a concrete benefit. Prefer asynchronous checks for operations such as network pings; a synchronous hook should need a demonstrated use case. Contributions could start with representative use cases and a small API proposal, informed by other object pools. No breaking change or particular API is assumed by this discussion.

Goal Explore measurable performance improvements to the competing MPMC queues introduced in #265. Preserve their delivery, strict bounded capacity, cancellation, and disconnection contracts. The existing mutex-based implementation is a valid baseline; a lock-free rewrite is not a prerequisite. Candidates to investigate Queue and waiter coordination. Shared uses a queue mutex plus separate sender and receiver semaphores, each with its own waiter lock. Profile lock acquisitions, cache contention, and retries after a notified task loses the race. Compare this with keeping queue state and waiter bookkeeping under one mutex before introducing more elaborate synchronization. Separate bounded and unbounded internals where useful. Both currently share capacity: Option<usize> and both semaphore fields, although unbounded sends never wait for capacity. A smaller unbounded state and a bounded-specific capacity model may simplify hot paths. Public endpoint types can stay unchanged. Bounded storag

Motivation The bounded MPMC queue added in #265 provides send and try_send, but lacks the capacity reservation API already available on bounded MPSC. Callers should be able to wait for space before constructing a message, or keep ownership of a message while racing a capacity wait against cancellation. Proposed API Add BoundedSender::reserve, BoundedSender::try_reserve, and a borrowed mpmc::Permit<'_, T>, following the existing MPSC API: pub async fn reserve(&self) -> Result<Permit<'_, T>, SendError<()>>; pub fn try_reserve(&self) -> Result<Permit<'_, T>, TrySendError<()>>; // On Permit<'_, T>: pub fn send(self, value: T) -> Result<(), SendError<T>>; Contract Queued messages, held permits, and capacity granted to pending waiters together must not exceed the configured capacity. A notification alone does not reserve a slot: the current MPMC wake-and-retry protocol needs explicit capacity ownership. Grant capacity in wait-queue order, as bounded MPSC does. New sends and reservations mu

Summary Add a runtime-agnostic asyncband::event::AutoResetEvent under the existing event feature. It should retain at most one unassigned signal and release one waiter per delivered signal, consuming the signal automatically when a wait succeeds. This fills the single-permit notification gap identified in the primitive survey. Related: #218. The manual-reset event issue #221 explicitly excluded auto-reset and Tokio-style single-permit notification semantics. Motivation A background worker or a serialized drain operation may need a payload-free "recheck the predicate" signal. Notifications must survive the interval between checking the external state and registering a wait, while repeated notifications without a consumer can coalesce. The existing primitives represent different contracts: Condvar does not retain notifications and coordinates waiting with a mutex-protected predicate. ManualResetEvent releases all registered waits and remains set for future waits until explicitly reset.