Deadqueue

Deadqueue is a dead simple async queue with back pressure support.

This crate provides three implementations:

• Unlimited (deadqueue::unlimited::Queue)

  • Based on crossbeam_queue::SegQueue
  • Has unlimitied capacity and no back pressure on push
  • Enabled via the unlimited feature in your Cargo.toml

• Resizable (deadqueue::resizable::Queue)

  • Based on deadqueue::unlimited::Queue
  • Has limited capacity with back pressure on push
  • Supports resizing
  • Enabled via the resizable feature in your Cargo.toml

• Limited (deadqueue::limited::Queue)

  • Based on crossbeam_queue::ArrayQueue
  • Has limit capacity with back pressure on push
  • Does not support resizing
  • Enabled via the limited feature in your Cargo.toml

Features

Example

use std::sync::Arc;

const TASK_COUNT: usize = 1000;
const WORKER_COUNT: usize = 10;

type TaskQueue = deadqueue::limited::Queue<usize>;

#[tokio::main]
async fn main() {
    let queue = Arc::new(TaskQueue::new(10));
    for i in 0..TASK_COUNT {
        queue.push(i);
    }
    let mut futures = Vec::new();
    for _ in 0..WORKER_COUNT {
        let queue = queue.clone();
        futures.push(tokio::spawn(async move {
            let task = queue.pop().await;
            assert!(task > 1);
        }));
    }
    for future in futures {
        future.await;
    }
    assert_eq!(queue.len(), 0);
}

Reasons for yet another queue

Deadqueue is by no means the only queue implementation available. It does things a little different and provides features that other implementations are lacking:

• Resizable queue. Usually you have to pick between limited and unlimited queues. This crate features a resizable Queue which can be resized as needed. This is probably a big unique selling point of this crate.

• Introspection support. The methods .len(), .capacity() and .available() provide access the current state of the queue.

• Fair scheduling. Tasks calling pop will receive items in a first-come-first-serve fashion. This is mainly due to the use of tokio::sync::Semaphore which is fair by nature.

• One struct, not two. The channels of tokio, async_std and futures-intrusive split the queue in two structs (Sender and Receiver) which makes the usage sligthly more complicated.

• Bring your own Arc. Since there is no separation between Sender and Receiver there is also no need for an internal Arc. (All implementations that split the channel into a Sender and Receiver need some kind of Arc internally.)

• Fully concurrent access. No need to wrap the Receiver part in a Mutex. All methods support concurrent accesswithout the need for an additional synchronization primitive.

• Support for try__ methods. The methods try_push and try_pop can be used to access the queue from non-blocking synchroneous code.

Alternatives

License

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.