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 12:11:01 GMT
> On Sun, May 13, 2001 at 09:51:37AM +0200, Sander Striker wrote:
> >...
> > 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.
>
> Huh? We aren't replacing pools with the sms stuff.

Oh oh, communication breakdown... Where did this go wrong?

> >...
> > 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).
>
> Yes, pools are mandatory. We make particular exceptions in a few
> cases. For those, we always register a cleanup with a pool to do
> the free(), so effectively, they are "ensured" to go away.

Ok.

> >...
> > 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
>
> Huh? I don't see us replacing the pool usage at all. Not migration either.
>
> I thought the intent was to use this stuff to help out with shared memory?
> That doesn't equal replacing the pool concept.

Ah, but the concept is the same, only more generic. It is just a question
of names and flexible backends. Oh, one distinction, using pools means
always to do tracking which is not neccesarily the case with sms (it depends
on which one you choose, and even on which parent it has - details).

I'm sorry to say that I am very tied up at the moment and I will probably
not be able to comment the next couple of days. Anyway, it won't be my
choice
anyway, it is up to the APR developers to set course.

> Cheers,
> -g

Sander


Mime
View raw message