> From: Greg Stein [mailto:[EMAIL PROTECTED] > Sent: 19 December 2001 22:45
[...] > 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/ Nice suggestion. I like it. The pseudocode is easily translated to real code. I could do this tomorrow after committing the APR_POOL_DEBUG code :) [as a patch, so people can review], Sander
