apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [ADDON] apr_malloc/apr_realloc/apr_free on per pool basis
Date Wed, 19 Dec 2001 21:45:24 GMT
On Wed, Dec 19, 2001 at 09:35:55PM +0100, Mladen Turk wrote:
> ----- Original Message -----
> From: "Sander Striker" <striker@apache.org>
> To: <dev@apr.apache.org>
> Sent: Wednesday, December 19, 2001 7:31 PM
> Subject: RE: [ADDON] apr_malloc/apr_realloc/apr_free on per pool basis
> > Please explain what you mean with this last line.  How is your mem usage
> pattern?
> > What are you doing that doesn't fit in the pools scheme?
> >
> Well, I'm working with satellite images that the smallest one is 1.7 GB, so
> I definitely need some kind of free scheme.

At a gross level, you could put each image into a pool of its own. When
you're done, you can either clear or destroy your pool.

Back to your patch:

I do like the notion of having new object type that is essentially "you can
alloc and free blocks, and as a catch-safe, everything will be freed when
the pool goes away."  (that is effectively the feature set that I see in
your patch)

However, I might suggest that a tracking list could be used, rather than a
complicated allocation scheme on top of pools. For example (pseudo-code):

apr_tracker_t * apr_tracker_create(apr_pool_t *pool):
   tracker = palloc(pool)
   tracker->pool = pool;
   apr_register_clean(pool, tracker, free_allocs);
   return tracker;

void * apr_tracker_alloc(apr_size_t *size, apr_tracker_t *tracker):
   mem = malloc(size + ALIGN(sizeof(track_item)));
   ti = (track_item *)mem;
   ti->prev = NULL;
   ti->next = tracker->item.next = ti;
   tracker->item.next = ti;
   return (char *)mem + ALIGN(sizeof(track_item));

   ti->prev->next = ti->next;
   ti->next->prev = ti->prev;
   free((char *)ti + ALIGN(sizeof(track_item)));

   cur = tracker->item.next;
   while cur != NULL:
       next = cur->next;
       free((char *)cur + ALIGN(sizeof(track_item)));
       cur = next;

In this version, you rely on malloc/free to provide optimal behavior. It
also means that memory will be returned to system at free time. In your
pool-based example, a "free" would only update some bits in your structures,
rather than send it all the way back to the system.

If malloc/free aren't fast enough for somebody, then they can always link in
a replacement, or the above code can be further tweaked for particular
systems, or configure-time options.

Personally, I'd prefer a tracker over your solution. I'd happily +1
something like above. (and probably suggest it goes into APRUTIL)


Greg Stein, http://www.lyra.org/

View raw message