Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 28843 invoked by uid 500); 19 Dec 2001 21:50:42 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 28816 invoked from network); 19 Dec 2001 21:50:42 -0000 From: "Sander Striker" To: "Greg Stein" Cc: Subject: RE: [ADDON] apr_malloc/apr_realloc/apr_free on per pool basis Date: Wed, 19 Dec 2001 22:52:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20011219134524.D17705@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Rcpt-To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Greg Stein [mailto:gstein@lyra.org] > 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