chenal 0.1.0-alpha.2

Performant channel implementations
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

//! # chenal
//!
//! Performant channel implementations.
#![warn(missing_docs)]
#![cfg_attr(docsrs, feature(doc_cfg))]
#![no_std]
extern crate alloc;

#[cfg(feature = "blocking")]
mod blocking;
pub mod capacity;
mod channel;
#[cfg(any(feature = "compat-tokio", feature = "compat-std",))]
pub mod compat;
pub mod errors;
mod internal;
mod loom;
pub mod mpmc;
pub mod mpsc;
mod rc;
pub mod spmc;
pub mod spsc;
mod waiter;

/// Reexport of [`aiq::sync`].
pub use aiq::sync;
pub use channel::{
    Channel, ChannelHalf, ChannelId, CloseGuard, CloseHandle, MRx, MTx, Rx, Tx, UMTx, UTx, Weak,
};

/// Future types.
pub mod futures {
    pub use crate::channel::{ClosedFuture, RecvFuture, SendFuture};
}

/// Default value for the `UNBOUNDED_BACKOFF` MPSC/MPMC channel parameter.
///
/// On some platforms like `x86_64`, `SeqCst` stores are significantly more expensive than
/// `Release` stores. That's why MPSC and MPMC channels use by default a modified algorithm
/// where `SeqCst` stores are replaced by `Release` stores, at the cost of having an
/// unbounded backoff loop in `recv` operation. It means that under specific circumstances,
/// i.e., `recv` called while the next message is being sent, [`spin_loop`] and even
/// [`yield_now`] are called repeatedly until the `send` operation finishes.
///
/// If this behavior is not desired, channel's `UNBOUNDED_BACKOFF` parameter might be set
/// to `false`, trading performance for scheduler friendliness.
///
/// [`spin_loop`]: core::hint::spin_loop
/// [`yield_now`]: blocking::std::thread::yield_now
pub const DEFAULT_UNBOUNDED_BACKOFF: bool = cfg!(any(
    target_arch = "x86_64",
    target_arch = "x86",
    target_arch = "riscv64",
    target_arch = "riscv32",
    target_arch = "powerpc64",
    target_arch = "powerpc",
    target_arch = "arm",
));