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: Memory Renaming (try 2)
Date Sun, 13 May 2001 07:51:37 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.

Heh heh, "at 01:03:31AM +0200" :-)
Let me see if I get your remark... I hope you imply that the only
thought goal was replacing the current apr_pool usage (which is
almost everywhere) with apr_sms.

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

I thought that pool usage was mandatory and that malloc/free should
never be called directly in apr (except within apr_pool, and now
in apr_sms).

> Furthermore, SDBM has extra calls to malloc/memset because it doesn't
> leverage calloc (which is probably a nod to its legacy origins).

apr_sms_calloc would indeed be a welcome extension.

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

I think you interpreted it as intended, you only took ik one step further
[which is IMHO a 'good thing(tm)', but really something that affects the
 entire APR and that means this is something for APR developers to talk

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

Exactly! For starters you won't need to convert the apr_pool code.
Just write the apr_sms_pool first and use it in parallel. When all
original pool usage is removed, the code can be dropped aswell. But this
is just my  fl 0.02 on the matter. I just hope that the sms api resembles
the pool api enough to implement all features the pool api has. For one
thing, the cleanup functions are not devided into groups, so this will
need work (I send in a trivial patch, but am not sure if this is the
way you want to go).

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

*lol* you must have really gotten frustrated with this stuff to actually
buy the standard. It is good to know someone actually has the standard
and can quote from it :-)

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

Err, not exactly. You have to make the distinction between top level
memory systems (like the sms_std one) and child memory systems (like
the sms_tracking one, sms_pool is also one).
Child memory systems may _never_ call system functions for memory allocation
themselves. Instead they have to call apr_sms_malloc(parent, size)
(or the equivalent in case of realloc/calloc/free). This way you can
have all the features pools have (like tracking and stuff), on top of
any memory allocation scheme.
You probably 'got' this already, but I just want to make sure.

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

I agree.

> My wayward $.02.  -- justin


View raw message