[Top][All Lists]

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

Re: [libmicrohttpd] Re: ITALY - memory pool

From: Carlos Henrique Júnior
Subject: Re: [libmicrohttpd] Re: ITALY - memory pool
Date: Wed, 15 Sep 2010 07:01:03 -0300

Why don't we have a parameter for max number of connections and memory per connection when creating the MHD server? I know that it's worst then having it at compile time, but it's a way better then nothing.

On Wed, Sep 15, 2010 at 4:07 AM, Christian Grothoff <address@hidden> wrote:
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:

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)

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


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]