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. >
