From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 12:47 PM
> FWIW, last week I wrote a very simple memory allocator (apr_malloc(),
> apr_calloc(), apr_free()) and replaced all the malloc/calloc/free calls in the
> apr-util/buckets with the apr_* calls. It was good for a 10% performance
> boost serving static pages on Windows. My allocator used intraprocess apr
> mutexs which are implemented as Win32 CriticalSections. There are probably
> better sync objects available (compare and swap) which would be good fora few
> more %.
>
> If anyone is interested, I'd be happy to post it to the list in all it's
> unfinished/unrefined glory.
+1!
This offers us the opportunity to add all sorts of validation to the server.
However...
we once discussed the possibility of extending the 'pool' concept to wrap any
sort of memory, in a manner that cleanups could always be introduced.
Creating a context (I think this is why we renamed to _ctx_ for a while) would
provide a scope. apr_free on a pool would be a noop, on a malloc would free.
Can we adopt the following?
apr_mem_alloc
apr_mem_alloc_clear
apr_mem_free
(mem_ could be m_ or simply m with no trailing underscore, your choice Bill).
The upshot? apr_ctx_alloc, free, etc (probably in apr-util) could delegate to
the appropriate apr_pool, apr_mem, or whichever implemented allocation schema
we have implemented.
But FirstBill, your functions appear very platform specific so they belong in apr.
