On Wednesday 15 September 2010 12:01:03 Carlos Henrique Júnior wrote:
> 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:
> >
> > #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