On Fri, Sep 23, 2016 at 09:24:46PM +0000, Boie, Andrew P wrote:
On Fri, 2016-09-23 at 16:46 -0400, Dmitriy Korovkin wrote:
Next, when I was saying of making reading thread wait if the bufferI contend this doesn't belong in the base ring buffer implementation
empty and writing thread wait if there is no free space, this does
resolve and does not intend to resolve the problem of several
threads trying to access the ring buffer - such a problem may be
either. I feel you are assuming that this policy of waiting is
appropriate for all situations and I disagree.
Ring buffers aren't just used in thread context. If an ISR wants to
stick something in the ring buffer, we can't wait here.
Also what if the thead would rather do something else than block if the
buffer is full? This is why the API returns -ENOSPC.
So I maintain that if you want to build something on top of base
ring_buffer.h for the common cases, that is fine, but don't assume they
are what's appropriate for all uses, the base API needs to stay how it
Point taken, and entirely valid. We won't touch the functionality of the
I think that we should still have the code to under kernel/ though, and
rename APIs to k_ring_buf_<whatever>.