[Libwebsockets] lwsac

Andy Green andy at warmcat.com
Tue Oct 16 00:47:48 CEST 2018



On 16/10/18 06:35, Per Bothner wrote:
> On 10/15/18 2:46 PM, Andy Green wrote:
> 
>> It replaces individual per-string or per-struct mallocs, and has the 
>> advantage when you're finished with it, you simply call an api to free 
>> the chunks, not the sub-allocations.
>>
>> https://libwebsockets.org/git/libwebsockets/tree/lib/misc/lwsac
> 
> Us old-fart GNU guys are reminded of obstacks:
> 
> https://en.wikipedia.org/wiki/Obstack
> https://www.gnu.org/software/libc/manual/html_node/Obstacks.html
> 
> I believe Stallman designed and implemented obstacks for gcc.

It's indeed similar, but obstacks troubles itself to track the 
sub-allocations

"...When all the objects in a chunk become free, the obstack library 
automatically frees the chunk (see Preparing for Obstacks). Then other 
obstacks, or non-obstack allocation, can reuse the space of the chunk. ..."

https://www.gnu.org/software/libc/manual/html_node/Freeing-Obstack-Objects.html#Freeing-Obstack-Objects

lwsac has literally zero overhead for aligned sub-allocations in the 
chunks... a million individual void * just take up the space of a 
million void * plus the per-chunk overhead you can control by selecting 
the chunk size.

There is no "objects in a chunk become free", they are allocated for the 
lifetime of the lwsac.  Only the lwsac itself gets freed.

It's not as flexible as individual object malloc (obstacks, since it 
lets you free objects, demanding tracking overhead is just a variety of 
that) but for cases where you weren't going to destroy anything in this 
container until you were going to destroy the container, it's 
potentially very advantageous.  There's no per-object overhead and no 
destroy unwinding, plus it can grow as needed like obstacks.

-Andy


More information about the Libwebsockets mailing list