Hi Nicolas, Thanks for the proposal, but I don't think this kind of patch belongs into MHD. malloc() performance is not critical for MHD at all, as MHD hardly uses malloc(): We mostly use our own custom memory pool, usually on top of mmap(), to avoid fragmentation issues and to limit memory consumption per TCP connection.
So I doubt you'd get _any_ performance delta by using Hoard. If I am wrong and you do have MHD-specific performance measurements that show that this is not premature optimization, please share them! Please also consider that there are allocation functions like strdup()/strndup(), and mixing allocators (malloc going to Hoard, strdup() to libc) is likely to end in disaster on free(). So in my view the only _good_ place to add the functions you propose (or Hoard itself) would be (GNU) libc. Happy hacking! Christian On 7/21/19 9:28 PM, Nicolas Mora wrote: > I happened to see that MHD doesn't allow to use different > malloc/calloc/free functions than the one provided by libc. > > This would be useful if the underlying app using MHD uses different > allocating functions like Hoard: http://www.hoard.org/ > More specifically, when using MHD_RESPMEM_MUST_FREE in a response > allocated with a different malloc() function, there would be problems. > > I can submit a patch for it. > Basically, I'd do it by adding functions like this: > > void MHD_set_alloc_funcs(MHD_malloc_t malloc_fn, MHD_calloc_t calloc_fn, > MHD_free_t free_fn); > void MHD_get_alloc_funcs(MHD_malloc_t * malloc_fn, MHD_calloc_t * > calloc_fn, MHD_free_t * free_fn); > > I didn't see any use of realloc() in the source code, so I wouldn't > allow to change it. > > Then, all internal call to malloc()/calloc()/free() would be replaced by > MHD_malloc()/MHD_calloc()/MHD_free() > > How about that? Any feedback? > > /Nicolas >
signature.asc
Description: OpenPGP digital signature
