apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: apr_memory_system.c;apr_memory_system.h
Date Sat, 05 May 2001 23:18:49 GMT
Hi,

> This is the stackable memory that the Samba TNG guys put together.  This
> is very impressive IMHO.  I believe this is the way to move forward with
> APR's memory requirements.  I would like to commit this to APR to get
> people hacking on this.  To that end, unless somebody objects, I will
> commit this on Monday morning.  Once it is committed, I expect people can
> use this to re-implement pools (same semantics, same API, just different
> under the covers), and shared memory.

I don't know if you are implying this, but in the long run the apr_pool_t
as it is present now in the code should be replaced by apr_memory_system_t.
This way you can plug in different memory systems in certain locations.
The pool memory system is just one of them.

It should be easy to implement the pool memory system.
The only exported function should be apr_pool_sms_create. Oh, and _don't_
use the standard memory system that is already implemented as a guide
on how to write a memory system. It does some things that should be
done differently in memory systems other than top level ones.
I'm happy to code up an example tracking memory system...

I would suggest that anyone implementing a memory system to read the
code to know exactly what is going on. We discussed this stuff a lot
and if there are things that seem strange please contact us, because
there will probably be a good explanation :^)
 
> Sander sent me a test program that he wrote, but I can't find it in my
> e-mail right now, hopefully Sander, you can re-send it to this list.
> Thanks.

Errr, I said that I would write up a test prog thingy this week and send
it to you, but I didn't get around :). I'll try tomorrow (same goes
for example sms).

> Of course, before I commit it, I will add all the headers and the Apache
> License, assuming the Samba guys don't object.

You have my approval. It would be nice to get a line of acknowledgement
somewhere, but that's not mandatory :).

One more suggestion (and some background):
I used very long type names and function names in this code. This was
done for clarity (I don't exactly like writing documentation, the code
is the doc). I would suggest shortening the function and type names.
Maybe s/memory_system/sms/g ? (at least for the main type apr_sms_t and the
commonly used functions apr_sms_malloc, apr_sms_free, apr_sms_realloc).

Btw, now that someone is actually interested in this code I went over it
again and did some minor adjustments that should go in. I'll send them
in together with the other stuff.

Sander

PS. If above text is a bit fuzzy it is probably due to the fact that it is
    1:10AM here...

Mime
View raw message