ringbuffer: versatility and optimizations#1101
ringbuffer: versatility and optimizations#1101Kijewski merged 8 commits intoRIOT-OS:masterfrom Kijewski:issue-979-2
Conversation
|
@kaspar030 can you review? |
|
Don't be afraid to review this change, please. ;) |
|
Looks good. If you are at it: could you write some unittests? |
|
I added the test for |
|
Is there a reason for you not using embunit? |
|
Is lazyness a valid reason? :-/ |
|
Since the framework takes most of the work away from you: no. |
|
But I had something laying around anyways: I'll send you a PR as soon as I fitted it to your PR |
sys/include/ringbuffer.h
Outdated
There was a problem hiding this comment.
s/rb_add_element()/ringbuffer_add_one()/
|
@authmillenon is 418e24e useful for your use case? |
|
I find it pretty complicated oO char *ringbuffer_allocate(ringbuffer_t *restrict rb, unsigned num, unsigned size); |
|
Because the buffer can wrap around. |
|
@authmillenon are you OK with my explanation, or do you think https://github.com/Kijewski/RIOT/commit/195061ad5c88e6bf4b76ef51bfaf16a0e47f394c isn't worth it? |
|
I do not really need it anymore and it seems very complicated for an "lightweight ringbuffer implementation", so I say: kick it out ;-) |
|
Rebased, and https://github.com/Kijewski/RIOT/commit/195061ad5c88e6bf4b76ef51bfaf16a0e47f394c unpicked. |
|
Ping. |
sys/include/ringbuffer.h
Outdated
|
Marked as "fix me first", because #935 depends on it. |
There was a problem hiding this comment.
Doesn't rb->avail give the number of available slots in the ringbuffer? Does this addition make sense here?
There was a problem hiding this comment.
Yes, an element is added to the tail, so the number of elements will be increased by one.
There was a problem hiding this comment.
Ah, I misinterpreted the meaning of available.
|
I made the test a unittest. |
|
As you added the unittests, I gues you can remove the old test?! |
This patch add `peek` functionality, and empty and full helpers.
It is a bad idea to use signed types for lengths. Mark pointers a `restrict`, since the ringbuffer is not thread safe anyway.
There is no need for an explicit pointer to the end of the buffer.
|
Rebased, old tests removed, typo fixed. |
|
looks good to me: ACK |
ringbuffer: versatility and optimizations
This is my second take on #933, to make the ringbuffer more versatile.
This PR is rebased on sys: rename ringbuffer functions #1099.unsignedtypes for lengths,restrict).sizeof (void *)bytes per ringbuffer.ringbuffer_add()won't overwrite existing content.ringbuffer_get_one()will tell what was overwritten.Please see the individual commits.