The following code panics after running for a while, because SpscRb::slots_free() returns a number bigger than SpscRb::capacity():

fn test_threads_count_underflow() {
    const SIZE: usize = 1024*8;
    const WRITE_BUF_SIZE: usize = 100;
    const READ_BUF_SIZE: usize = 2048;
    const ITERATIONS: usize = 1000000;
    let rb = SpscRb::new(SIZE);
    let producer = rb.producer();
    let consumer = rb.consumer();
    let in_data = [0; WRITE_BUF_SIZE];

    thread::spawn(move || for _ in 0..ITERATIONS {
        producer.write_blocking(&in_data).unwrap();
        thread::sleep(time::Duration::from_millis(12));
    });

    for _ in 0..ITERATIONS {
        let mut buf = [0; READ_BUF_SIZE];
        if rb.count() < READ_BUF_SIZE {
            continue;
        } else {
            consumer.skip(rb.count() - READ_BUF_SIZE).unwrap();
            consumer.get(&mut buf).unwrap();
        }
    }
}

This is the panic message:

---- test_threads_count_underflow stdout ----
	thread 'test_threads_count_underflow' panicked at 'attempt to subtract with overflow', rb/src/lib.rs:243:9

https://github.com/klingtnet/rb/blob/master/src/lib.rs#L288

Does not check that the consumer read enough bytes to allocate the entire producer buffer. Thus with producers writing blocks larger than what the consumer consumes will corrupt the ring overwriting data that hasnt been read.

A similar issue may exist on read_blocking if the producer doesnt produce enough data.
https://github.com/klingtnet/rb/blob/master/src/lib.rs#L374

This makes the project setup a bit easier and removes external service dependencies.

At the moment rb is licensed under GPLv3 but this is subject of change until there is a 1.0 release. If you've any concerns about using the GPL license, please leave a comment in this issue.

I still have to learn the differences between the all the major open-source software licenses. Luckily there is tldrlegal.com which helps a lot for this task.

If I understand it all right, any usage of locks in read/write methods makes the library unsuitable for realtime applications. It is mostly explained here http://atastypixel.com/blog/four-common-mistakes-in-audio-development/ — if producer&consumer have different priorities, locks will lead to "priority inversion" problem.

Not sure if there's another way to do it in "safe" language subset though.

This library was written before there were any Rust editions and in the meantime we have reached Rust 2021. With each Rust edition some defaults and best practices have changed. The rust docs should be a good place to start getting an overview of the changes.

Update the code to follow best practices of the latest Rust edition, that is Rust 2021.