apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: APR memory systems
Date Wed, 09 May 2001 11:09:32 GMT

If we're going to have a whole load of different "plug-ins" for different
types of memory allocation/viewing, and some of these will of course look
different for different platforms, can we split out the "standard memory
system" functions into their own file as well?  That should help expose the
build issues quicker and give the structure more beef.

In other words, add a file (apr_standard_memory_system.c??) containing the
standard functions,
static void *apr_standard_memory_system_malloc(apr_memory_system_t
*memory_system, size_t size)

static void *apr_standard_memory_system_realloc(apr_memory_system_t
*memory_system, void *mem, size_t size)

static void apr_standard_memory_system_free(apr_memory_system_t
*memory_system, void *mem)

apr_status_t apr_standard_memory_system_create(apr_memory_system_t


> Hi everyone,
> Sorry for the version mix up. This one is clearly the
> latest, since it has some signs of our locking discussion
> in it.
> From recent input on this list it is clear that the
> current threadsafe_lock()/unlock() functions don't cut it.
> We will need to work out how these functions should look.
> I compile tested the code with gcc on a
> custom linux system (kernel 2.4.2, glibc 2.2.2) without
> warnings.
> Second I compile tested the code on Windows 2000 SP1
> using VC++ 6.0 SP3 without warnings.
> Attached are the sources.
>  apr_memory_system.[ch]    core (using apr_stuff.h), includes
>                            standard memory system.
>  apr_stuff.h               hacked up include file to compile
>                            without APR
> I hope someone among you will fix up the include thingies :-)
> More attachments:
>  apr_tracking_memory_system.[ch]  example of a tracking
>                                   memory system implementation.
> Sander

View raw message