apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Memory Renaming (try 2)
Date Sun, 13 May 2001 00:07:59 GMT
On Sun, May 13, 2001 at 01:03:31AM +0200, Luke Kenneth Casson Leighton wrote:
> > > Oh, here is in an incredibly useful suggestion that I'd love to see
> > > added into the sms stuff while you are at it - add a calloc function that
> > > tries to use calloc if available, or use malloc/memset.  There are
> 
> 
> interesting to note that people are considering actually using this
> _outside_ of apr_pool.  hm.

I believe that you guys are touting this as a replacement for malloc,
free, etc (so that you can do in-kernel memory allocation).  If this 
is our way (and I really don't have much to say in this one way or
another), then don't we need to change all usage of malloc/free in 
APR (or APR-based programs) to this?  Otherwise, what's the point of 
having this?  Not everyone uses a pool.  But, for the case I mentioned 
(apr-util's SDBM), it uses malloc, free directly - it'd be preferable, 
I think, to to use this new apr_sms_t instead.  Furthermore, SDBM
has extra calls to malloc/memset because it doesn't leverage calloc
(which is probably a nod to its legacy origins).

Now, I may be completely misunderstanding your intentions for apr_sms_t,
but that is how I interpreted it.  Please correct me if I am wrong.

And, really, I'd think that a pool should be defined in terms of a 
apr_sms_t as well (I'm not sure if this is what you are saying, too).  
It'd be a nightmare to convert the code, but I think it gets us closer 
to what we want.  A pool is just another apr_sms_t, which happens to
be built on top of the "standard memory system."  I don't believe 
everyone needs to use apr_pool_t, but everyone probably needs apr_sms_t 
(unless you only allocate from the stack).

> suggestion:  in a separe module, create apr_sms_util.c.
> 
> this contains apr_sms_calloc(), and other things such as, oh,
> i dunnno: perhaps a routine to emulate realloc() fo those
> tmemory systems that don't have one, or uses the realloc if it does.

IMHO, calloc is in the same league as malloc, free, realloc.  ISO C 
requires calloc as it does for the other three.  For the standard case,
you shouldn't need to emulate these on all but the most brain dead 
platforms.   These are the four that are required by C99 (and I believe 
C89 does too - I just bought the 554-page C99 standard for $18 from 
ansi.org because we keep having these debates about what is in the 
standard or not...).  It seems silly to implement a memory system that 
is not a superset of what is offered by the base language itself.  

And, I think that all of the other memory systems will just have to 
have the same contract as ISO C's for these functions (i.e. they have 
to act the same, but they can grab or free the memory however they 
wish).  So, if someone calls apr_sms_calloc, they better return back a
memory space of the specified size zeroed out (or NULL if no more space
is available) - no matter what the underlying system is (shared memory,
kernel, user space, etc.).

My wayward $.02.  -- justin


Mime
View raw message