[Libwebsockets] lws_ring_get_count_free_elements() question/remark

andy at warmcat.com andy at warmcat.com
Wed Mar 31 07:46:23 CEST 2021

On March 31, 2021 3:49:48 AM UTC, Olivier Langlois <olivier at olivierlanglois.net> wrote:
>I was in the process of doing 4 by writing my own implementation when I
>was reviewing that code.
>I do use your lib from C++ and I didn't like the fact that the payload
>buffer had to be allocated/freed each time my program wanted to send a
>message. (and the ring size mismatch didn't feel right to me too. I did
>fix it in my implementation!)

How you deal with items in the ring is up to user code, nothing in the ring is related to allocations.

>Payload buffer is now implemented with std::vector (with a special

Whoop de woo.

>allocator that skips new chars initialization) that is only resized
>before using it. (ring is now a class that destroys all those vectors
>when the ring object is destroyed. this is something that wasn't
>possible with the lws element disposal function pointer).
>Now my equivalent of get_count_free_elements() and
>get_count_waiting_elements are inline functions simply returning a
>counter or ring size - waiting counter.
>As a lib user, I like when the lib does not something unexpected. If I
>ask the lib to create a 16 elements ring, I expect to get a 16 elements
>ring. Not a 15 elements one.

That's great, you should put it out there so you can deal with people like yourself using it :-)

>This is not a major issue but it is an issue. I have reported it. Now,
>you can do what you want with it. It is your call.

Gee, thanks.


>Have a nice week Andy!
>On Tue, 2021-03-30 at 17:26 +0100, Andy Green wrote:
>> On 3/30/21 5:16 PM, Olivier Langlois wrote:
>> > Hi,
>> > 
>> > If I read misc/lws_ring.c
>> > 
>> > empty ring with a given COUNT,
>> > 
>> > lws_ring_get_count_free_elements() will return COUNT-1.
>> > 
>> > Is that correct?
>> > 
>> > I kinda understand that if head == tail, you cannot differentiate 
>> > incremented to reach the same value of tail. Therefore, to avoid
>> > this 
>> > ambiguity, only the tail is allowed to make that move.
>> > 
>> > I see 2 ways that this could be resolved:
>> ... there's another two ways, 3) just accept that's how that works,
>> or 
>> 4) just use some other implementation...
>> > 1. In lws_ring_create(), allocate an extra element so that an empty
>> > ring 
>> > does have the # of requested free elements
>> > 2. Maybe if struct ring had a waiting_elem count, this would remove
>> > this 
>> > ambiguity and would allow the code to not waste an element. By
>> > assuming 
>> > that the element size is significantly bigger than an extra int,
>> > this 
>> > added struct member would be justified memory wise.
>> What's the problem if you just tell it +1 size for the ringbuffer
>> from 
>> user code?
>> -Andy

More information about the Libwebsockets mailing list