On Wed, Dec 19, 2001 at 09:35:55PM +0100, Mladen Turk wrote:
>
> ----- Original Message -----
> From: "Sander Striker" <[EMAIL PROTECTED]>
> To: <[email protected]>
> 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));
free:
ti->prev->next = ti->next;
ti->next->prev = ti->prev;
free((char *)ti + ALIGN(sizeof(track_item)));
cleanup:
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)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
