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.
> Us old-fart GNU guys are reminded of obstacks:
> I believe Stallman designed and implemented obstacks for gcc.
It's indeed similar, but obstacks troubles itself to track the
"...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. ..."
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.
More information about the Libwebsockets