7 releases (2 stable)

1.0.1 Aug 29, 2023
1.0.0 Dec 3, 2022
0.1.7 Aug 21, 2021
0.1.5 Jun 28, 2021
0.1.3 Jun 29, 2020

#65 in Concurrency

Download history 988/week @ 2023-08-09 966/week @ 2023-08-16 1282/week @ 2023-08-23 1204/week @ 2023-08-30 1283/week @ 2023-09-06 1480/week @ 2023-09-13 1432/week @ 2023-09-20 1078/week @ 2023-09-27 1006/week @ 2023-10-04 1008/week @ 2023-10-11 1180/week @ 2023-10-18 1523/week @ 2023-10-25 1584/week @ 2023-11-01 1520/week @ 2023-11-08 1268/week @ 2023-11-15 803/week @ 2023-11-22

5,497 downloads per month
Used in 2 crates (via deepwell)




Build Status License Cargo Documentation Rust 1.36+

This crate provide channels used between async-async or async-blocking code, in all direction. Implmented with lockless in mind, low level is based on crossbeam-channel


Faster than channel in std or mpsc in tokio, slightly slower than crossbeam itself (since async overhead to wake up sender or receiver).

Run the benchmark tests to see for yourself:

cargo test performance --release -- --nocapture --test-threads=1



Add this to your Cargo.toml:

crossfire = "0.1"

extern crate crossfire;
extern crate tokio;

use crossfire::mpsc;

// async-async

let (tx, rx) = mpsc::bounded_future_both::<i32>(100);
tokio::spawn(async move {
    for i in 0i32..10000 {
        let _ = tx.send(i).await;
        println!("sent {}", i);

loop {
    if let Ok(_i) = rx.recv().await {
        println!("recv {}", _i);
    } else {
        println!("rx closed");

mpmc & mpsc package is almost the same, while mpsc has some optimization becauses it assumes only one consumer.

Error types are re-exported from crossbeam-channel.


Supports stable Rust. Mainly tested on tokio-0.2 (Not tested on async-std or other runtime). future::selects and timeout work fine, but it takes advantage of runtime behavior not documented by Rust official.

Refer to https://github.com/rust-lang/rust/issues/73002

Memory overhead

While using mp tx or mp rx, there's memory overhead to pass along wakers for pending async producer or consumer. Since waker is small, the overhead can be ignored if your channel is busy. Canceled wakers will be eventually cleanup by later send/receive event. If the channel is used for close notification (which never trigger) in combine with futures::select, currently there's hard coded threshold to clean up those canceled wakers.


This channel implementation serves in various components of our storage engine, you are welcome to rely on it.


~36K SLoC