libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libmicrohttpd] Re: ITALY - memory pool


From: Christian Grothoff
Subject: [libmicrohttpd] Re: ITALY - memory pool
Date: Wed, 15 Sep 2010 09:07:29 +0200
User-agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.4.5; i686; ; )

Dear Enrico,

I realize how embedded developers usually do their fully-static memory 
allocations.  MHD uses malloc in a few places (not too many, we've been 
careful).  Given that for even slightly larger systems malloc is the right 
choice, I'm not sure how to fix this -- especially since many of the 
parameters, such as the number of connections and memory per connection, are 
simply not usually known at compile time for MHD, so changing this in a way 
that would keep everything dynamic for other systems won't be trivial.

My best idea right now would be for you to define a malloc-macro which you 
then map to a function that accesses you static pool.  Something like this:

#ifdef STATIC_ALLOCATION_ONLY
void * static_malloc (size_t size, const char*pool);
#define malloc(a) static_malloc(a, __FUNCTION__)
void static_free (void *ptr);
#define free(p) static_free(p)
#endif

then, you use "__FUNCTION__" in static_malloc to access the right static pool 
that you manage manually.  That would mean you only have a tiny change in 
platform.h and linking in of a new C file with the static allocator functions. 
Naturally, the above only works nicely as long as there is at most one malloc 
for a given block size per function, but        I think that's easily the case 
here.

My 2 cents

Christian

On Saturday 11 September 2010 23:21:47 you wrote:
> Hi Christian,
> 
> I'm reading the code, file by file.
> 
> I noticed that the following file:   memorypool.c
> contains a malloc() call.
> 
> Embedded systems usually prefer not to allocate memory at run time because
> the programmer wants to know in advance the RAM footprint.
> 
> If the application requires a pool, they do the following:
> 
> 1) They statically allocate a vector of a known size   (#define  POOL_SIZE
> 1024)
> 2) They define the size of a chunk   (#define  CHUNK_SIZE   (POOL_SIZE /
> 4)) 3) They write some pool management functions
> 
> 
> It takes me 10 minutes to modify the code to add this feature, but I would
> like to decide a common approach to any code modifications that I might
> have to do.
> 
> What do you think?
> 
> 
> 
> My goal is to use your code in an ARM7 CPU with the following
> characteristics:
> 
> RAM = 96 kbyte
> FLASH = 512 kbyte
> CODE EXECUTION = in place
> 
> To be honest, 50% of the memory is needed by the application.
> 
> 
> Ciao,
> Enrico



reply via email to

[Prev in Thread] Current Thread [Next in Thread]