Re: [libmicrohttpd] why

[Christian Grothoff]

There are various benefits:

1) forcing the use of mmap() -- and uniform sizes for all requests --
ensures that we don't suffer from memory fragmentation, which is what
would happen if we allocate lots of different-sized tiny bits based on
say HTTP request headers;
2) using our per-request pool ensures that a request will not consume
more memory than granted, without us having to track the amount of libc
allocations made;
3) it avoids having to deal with deallocation of individual (smaller)
bits, we can just blow away all allocations made per-request in one big
swoop. This is less code and faster.
4) pointer-bumping allocation is faster than traditional malloc/free;
5) we use a particularly tricky variant with allocation from bottom and
from the top of the area, with the middle being the 'free' range, so we
_can_ not only do pointer-bumping allocation but in some cases also
pointer-bumping *deallocation* for the IO buffer.

So in short: faster, simpler, safer.

-Christian

On 3/4/21 11:15 AM, folkert wrote:
> Hi,
> 
> While going through the libmicrohttpd sources, I noticed this part in
> daemon.c:
> 
> /* Allocate memory pool in the processing thread so
> * intensively used memory area is allocated in "good"
> * (for the thread) memory region. It is important with
> * NUMA and/or complex cache hierarchy. */
> connection->pool = MHD_pool_create (daemon->pool_size);
> 
> I'm curious why libmicrohttpd is doing its own memory management.
> If I remember correctyl the memory allocater of glibc has pools of
> memory per thread? It does keep freed() memory in a per-thread list
> before it is moved to the global pool of free memory.
> 
> 
> Regards.
>