Should the RingBuffer be Send?
I think this might be useful.

It could probably even be Sync, even though this could only be used to get its capacity. But why not?

Could/should the Producer/Consumer be RefUnwindSafe?

What about the other structs?
Are they missing any marker traits?

I have code like this in two places in my application now:

        while let Ok(AudioEngineToGUIMessage::BufferSizeChanged(_)) = from_audio_rx.peek() {
            if let Ok(AudioEngineToGUIMessage::BufferSizeChanged(frames)) = from_audio_rx.pop() {
                let mut buffer_size_frames = buffer_size_frames.borrow_mut();
                *buffer_size_frames = frames;
            } else {
                unreachable!("AudioEngineToGUIMessage not a BufferSizeChanged message?!")
            }
        }

The while let immediately followed by if let feels verbose and hacky... is there a better way to do this?

Can a method to take ownership of the items in a ReadChunk be added? I'm not sure what the best API would be (perhaps an consume_into_iter()?) since taking ownership means commit must be called, but such a method would be crucial for efficiently batch-reading non-Copy types.

(Context: using rtrb as a primitive in a scheduler, so it contains non-Clone non-Copy jobs rather than u8s or anything of that sort)

I've never needed this, but I've seen that it's implemented in:

https://github.com/Ralith/oddio/blob/edfec45801ea88f130cd0be719298b9c12673469/src/spsc.rs#L95-L99

and

https://github.com/Ralith/oddio/blob/edfec45801ea88f130cd0be719298b9c12673469/src/spsc.rs#L134-L138

I guess this could also be implemented with Arc::strong_count().

Does anyone need this?

Are there any downsides to implementing this?

I have suspicion that this might become one of the more important crates in the ecosystem. So, it might make sense to:

• Document minimal supported rust version (MSRV)
• Document MSRV policy (how many rustc versions back are generally supported? is MSRV a semver-breaking change?)
• Add CI job for MSRV

Is there a better way to block until you have something to pop other than:

while input.is_empty() {}
let x = input.pop().unwrap();

?

WriteChunkUninit::producer is typed as &'a Producer<T>.
But ReadChunk::consumer is typed as &'a mut Consumer<T>.

With current code, switching their mutability never makes compiler error.
But inconsistent mutability between them seems to be weird.
So I think we should mark both of them as mut or both of them as not mut .

Hi thanks for the crate!

I'm looking for advice on what the best way to just drop all of the data in the buffer from the consumers side.

Currently I'm just doing a while let loop on pop() and ignoring the result. Is there a better way to do this? Say in the case where we only want to consume the first 10 elements, drop the rest, and then consume 10 more later?

I apologize if this question is silly, but why does ReadChunk.as_slices() return two slices?

I (perhaps naively) expected ReadChunk to have a method .as_slice() which returns a single slice containing all elements in the chunk. I suspect there is a good reason why we use .as_slices() instead.

Perhaps it would be helpful to add an explanation of the motivation behind this API to the doc comments.

Thanks a lot for this crate. Are there any plans of adding async support?

Hi, thanks for the great library!

Here's my use-case: This is a low latency application. Thread A sends elements over a spsc channel to Thread B. The elements contain heap-allocations, e.g: String. (I know, this is funny to have both "low latency" and "heap allocated elems" in the same system, but that's it)

With any popular queue solution, including rtrb, popping takes ownership of the elem, making the consumer eventually Drop it (unless it does not send the consumed elem back using a different channel). This makes Thread A continuously allocated, and Thread B continuously deallocate, eventually making them contending for the same lock. This has measurable effects.

To solve this issue, I ported my C++ queue to rust: https://github.com/erenon/cueue
This has the following differences compared to rtrb:

• It default inits every elem in the queue (This requires T to be Default)
• It does not drop consumed elems, but leaves them in the queue as-is. This avoids heap ping-pong.
• The produced elems are returned to the producer (in the write_chunk): this allows re-use of resources.
• It employs an mmap trick that makes the queue truly circular. This makes the internal logic a bit simpler, and the reader/writer interface a bit nicer (e.g: reader always returns a single slice, not two).

Perhaps some ideas can be salvaged to make rtrb even better? (I would prefer the widely used rtrb over my tiny lib, if it was possible) Thanks!

In an attempt to use rtrb in my code (mostly through its Read and Write implementations), I've noticed that occasionally a few hundred bytes gets lost. How can I debug whether this would be a rtrb issue? Has rtrb undergone loom-based rigorous testing, or anything of that sort?

Hey! First off, thank you for this amazing crate. I'm using it for real-time data processing for a radio telescope, which works wonders.

If possible, I would like a function to query "percent fullness" or something to that end so I can log warnings when we get close to the end. This would help me catch cases where my consuming code can't keep up with production.

Thanks again!

The JACK ring buffer provides this, see https://jackaudio.org/api/ringbuffer_8h.html#aeb059ff23c65389d48ebbe948f05c2b2.

The libc crate seems to be able to do this:

https://docs.rs/libc/0.2.79/libc/fn.mlock.html
https://docs.rs/libc/0.2.79/libc/fn.munlock.html

It should be simple to add this as a method to RingBuffer.

The JACK wrapper also provides it:

https://docs.rs/jack/0.7.0/jack/struct.RingBuffer.html#method.mlock

Windows might need special treatment with https://docs.rs/winapi/0.3.9/winapi/um/memoryapi/fn.VirtualLock.html?

Do we have to expose mlock() as unsafe?

Probably it would be better to simply provide an (unsafe?) method to expose the underlying memory as a pointer?

The second part of this comment isn't true anymore:

... since I removed the Copy trait bound in 148cf65.

If commit(n) is called with n smaller than the chunk size, the remaining slots (which have been Default-initialized before) will be leaked.

This can be fixed by calling drop_in_place() on the affected slots.

RingBuffer was allocated by allocating Vec, then extract pointer, and forget Vec.
Just using alloc::alloc::alloc(Layout::array::<T>(capacity).unwrap()) seems to be more natural.
Why is this done?

Hi, I'm considering using this crate but am unsure whether the performance is any better than the other SPSPC wait free ringbuffers. A comparison to crossbeam_channel might also be merited, since I could see using their bounded queues in a very similar way to the ringbuffer.

Now, I read all slots from Consumer by this:

  let result = consumer.read_chunk(consumer.slots());

But sometimes I don't care how many slots hold by RingBuffer, I just want to read all slots.

Do you think it's a good idea to add a method for Consumer like this:

  let (all_slots_size, chunks) = consumer.read_all();

For an extremely niche use case with smoltcp, from what I understand this could just be added with the current API since the ReadChunk has exclusive access to its data already

This has been discussed in #57.

I think the API for writing would be straightforward and the implementation could use the existing write_chunk_uninit() method.

I'm less sure about the API for reading. I guess users could provide an already initialized slice onto which the data will be copied.
However, it might be more efficient in some cases if the user could provide some kind of uninitialized slice.

I think it would be useful to provide those methods for T: Copy types, because under the hood memcopy() or memmove() will be used for maximum efficiency.
I'm not sure if it would also make sense for less constrained types.

We have previously been relying on the undocumented synchronization in Arc::strong_count().
This has been removed in rust-lang/rust#115546, which broke is_abandoned().

There have been others who were surprised by the change: rust-lang/rust#117485

For reference, this is the documentation: https://docs.rs/rtrb/0.3.0/rtrb/struct.Producer.html#method.is_abandoned

As an example, see agerasev/ringbuf@ec34c53

The Arc<RingBuffer> field on Consumer and Producer is made public, which is unsound. Overwriting the buffer field without updating head and tail can cause a read from uninitialized memory without unsafe code in downstream crates.

If the RingBuffer needs to be exposed, then I would recommend a method returning a shared reference instead of a public field.

I initially thought that this wouldn't be necessary, but I came up with one hypothetical situation:

If there are multiple slices that are supposed to be all added up and written to the ring buffer, the first slice could use copy_to_uninit() and the remaining ones would add themselves to the already written data.
However, for (safely) adding Ts a &mut [T] would be needed.

This would be a breaking change.

Currently it is possible to create a ring buffer with a given number of chunks with RingBuffer::with_chunks(..., ...) (introduced in #17). This guarantees that - if only the "chunks" API is used - the second slice of each chunk will be empty.

I think this is good because it allows a simple and very efficient usage.
However, what's not good is that this goes behind the back of the compiler. The second slice is still presented to the user and only the user (and not the compiler) knows that it's empty.

I think it would be good to add something like ChunkProducer and ChunkConsumer that only provide single fixed-size slices and they don't allow single-element push()/pop() at all.

Note that both ends of a RingBuffer (producer and consumer) can independently have the "fixed chunk size" property.
This means there should be four different constructors, yielding

• (Producer, Consumer)
• (ChunkProducer, Consumer)
• (Producer, ChunkConsumer)
• (ChunkProducer, ChunkConsumer)

The with_chunks() constructor should probably be deprecated or completely removed.
The split() function probably has to be replaced with something else that allows the four different cases mentioned above.
This would very likely be a breaking change, requiring a version bump to 0.2.

The "classic" Producer and Consumer would still have the write_chunk()/read_chunk() API, which allows changing the chunk sizes during runtime.

The ChunkProducer could have an API like this:

fn write_slice(&mut self) -> WriteSlice;
unsafe fn write_slice_uninit(&mut self) -> WriteSliceUninit;

The WriteSlice could probably implement DerefMut<Target = [T]> to allow writing to the chunk and it could have a Drop implementation that commits the written data to the ring buffer.
WriteSliceUninit would implement DerefMut<Target = [MaybeUninit<T>]>. Calling write_slice_uninit() would be unsafe because the user would have to ensure that the whole slice is initialized before Drop::drop() is called (including when a panic occurs).

The ChunkConsumer could have this API:

fn read_slice(&mut self) -> ReadSlice;

The ReadSlice would implement Deref<Target = [T]> to allow reading data and Drop to advance the read index.

I'm not sure if that's necessary, but it could probably also have something like this:

fn peek_slice(&self) -> &[T];

Does that sound like a good idea?