apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject RE: apr_memory_system.c;apr_memory_system.h
Date Sun, 06 May 2001 23:59:02 GMT

> > 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.

Yes, that was what I was thinking as well.

> > 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).

Well, that explains why I couldn't find it.  :-)  Sorry, it has been a
very long week, and I thought I had seen it.

> > 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 :).

When I commit it tomorrow, you will be acknowledged in the file itself.
Just for completeness, can Luke and Elrond give their okay's too.  If they
didn't write the code.  Just need to be sure that I don't put a license on
this code that you three don't agree with.

> 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).

I'll commit it as is, and let everybody munge on it at their leisure.

> 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.



Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message