refactor(mpsc): simplify receiver wake gating
3 files changed
tree: f796100b36499c4aa8a7181d858a66d7072ca110
  1. .cargo/
  2. .github/
  3. asyncband/
  4. benchmarks/
  5. examples/
  6. tests-integration/
  7. xtask/
  8. .asf.yaml
  9. .editorconfig
  10. .gitignore
  11. AGENTS.md
  12. Cargo.lock
  13. Cargo.toml
  14. CHANGELOG-OLD.md
  15. CHANGELOG.md
  16. DISCLAIMER
  17. HISTORY.md
  18. LICENSE
  19. licenserc.toml
  20. MIGRATE.md
  21. NOTICE
  22. README.md
  23. RELEASE.md
  24. rustfmt.toml
  25. taplo.toml
  26. typos.toml
README.md

Apache Asyncband (Incubating)

Crates.io Documentation MSRV 1.86 Apache 2.0 licensed Build Status

[!IMPORTANT]

Apache Asyncband (incubating) is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Incubator PMC.

Please read the DISCLAIMER and a full explanation of “incubating”.

Asyncband was formerly published as MEA. The mea crate is deprecated and receives no further development. See the migration guide for migration instructions and details about the rename.

Overview

Asyncband is a focused collection of composable, runtime-agnostic concurrency building blocks for async Rust. It provides synchronization, initialization, task coordination, channels, resource reuse, and workload control without choosing an executor for the application.

Asyncband's async APIs are built on standard futures and wakers. The library does not spawn tasks, own worker threads, install timers, or require a reactor or I/O driver. Applications can poll its futures with Tokio, async-std, smol, a custom executor, or any other standards-based runtime, and compose runtime services such as deadlines around them.

Project scope

The project is not limited to small or stateless synchronization primitives. Stateful utilities such as a singleflight group or an object pool fit when they provide a generally reusable coordination mechanism and remain independent of executor policy.

The boundary is mechanism versus policy. Task placement, timers, deadlines, retries, periodic maintenance, and application lifecycle orchestration stay with the caller and its runtime. Potential future-concurrency or scheduling APIs are evaluated against the same boundary: they must remain executor-independent and compose with caller-owned execution and timing.

Getting started

The crate enables no APIs by default. Enable only the features your application uses:

cargo add asyncband --features mutex
use asyncband::mutex::Mutex;

async fn increment() {
    let counter = Mutex::new(0);
    *counter.lock().await += 1;
    assert_eq!(*counter.lock().await, 1);
}

Public paths stay direct—such as asyncband::mutex, asyncband::pool, and asyncband::once::OnceCell—while Cargo features keep unused implementations out of the build.

Examples

Runnable examples live in the examples workspace crate. They demonstrate how to choose and compose Asyncband primitives in complete programs.

API map

AreaAPIFeatureUse
Shared stateMutexmutexProtect shared data with asynchronous mutual exclusion.
RwLockrwlockAllow multiple readers or one writer.
CondvarcondvarWait for notifications while releasing a mutex.
InitializationOnceonceRun asynchronous initialization exactly once.
OnceCellonce-cellInitialize and store one asynchronous value.
LazyCelllazy-cellLazily initialize a value with a stored asynchronous function.
OnceMaponce-mapInitialize and store one value per key.
Task coordinationBarrierbarrierWait until all participants reach a synchronization point.
LatchlatchWait until a one-way countdown completes.
WaitGroupwaitgroupWait for a dynamic group of tasks to finish.
ShutdownshutdownCoordinate shutdown signals and completion.
ChannelsoneshotoneshotSend one value between two tasks.
mpscmpscSend each value from multiple producers to one receiver.
broadcastbroadcastBroadcast values from one or more producers and retain them until every active receiver consumes them.
Resource reusepoolpoolReuse objects through bounded or unbounded pool variants.
Workload coordinationSemaphoresemaphoreControl concurrent access with permits.
GroupsingleflightCoalesce concurrent calls for the same key.
Sync interopFutureExtblockingDrive one runtime-agnostic future from a blocking thread.

Synchronous interoperability

The optional blocking module is a boundary adapter for synchronous callers. It parks the calling thread while driving one future; it is not a general-purpose executor.

cargo add asyncband --features blocking,oneshot
use std::thread;

use asyncband::blocking::FutureExt as _;
use asyncband::oneshot;

let (sender, receiver) = oneshot::channel();
thread::spawn(move || {
    let result = 6 * 7;
    sender.send(result).unwrap();
});

assert_eq!(receiver.block_on(), Ok(42));

Async first, blocking by adaptation

Async and synchronous synchronization primitives have different optimization constraints. Once an async operation is exposed as a runtime-agnostic future, synchronous code can usually drive that future through a block_on adapter. Asyncband therefore designs its primitives for async use and provides blocking interoperability at the boundary instead of duplicating synchronous methods across every type.

A sync-first implementation can exploit OS- or platform-specific facilities that an async implementation cannot assume. Libraries focused on synchronous code can therefore make different and sometimes better tradeoffs. Asyncband leaves those optimizations to dedicated libraries rather than treating blocking adaptation as a second family of primitives.

Execution constraints

The blocking module is a lightweight, thread-parking single-future executor, not a general-purpose async runtime. wait_timeout drops the future on timeout. Futures that depend on a runtime-specific timer or I/O driver still need that runtime's driver to make progress, and blocking an executor thread can cause starvation or deadlocks. See the blocking module documentation for the full contract.

Thread safety

Asyncband types implement Send and Sync only when the protected, transferred, or managed value satisfies the necessary bounds. See each API's documentation for its exact contract.

Minimum Supported Rust Version (MSRV)

This crate is built against the latest stable release, and its minimum supported rustc version is 1.86.0.

The policy is that the minimum Rust version required to use this crate can be increased in minor version updates. For example, if Asyncband 1.0 requires Rust 1.20.0, then Asyncband 1.0.z for all values of z will also require Rust 1.20.0 or newer. However, Asyncband 1.y for y > 0 may require a newer minimum version of Rust.

License and Trademarks

This project is licensed under Apache License, Version 2.0.

Apache Asyncband, Asyncband, and Apache are either registered trademarks or trademarks of The Apache Software Foundation in the United States and/or other countries.

History

See HISTORY.md for the external implementations that informed Asyncband's APIs.