Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 25255 invoked by uid 6000); 7 Sep 1999 23:00:22 -0000 Received: (qmail 25246 invoked from network); 7 Sep 1999 23:00:20 -0000 Received: from twinlark.arctic.org (204.107.140.52) by taz.hyperreal.org with SMTP; 7 Sep 1999 23:00:20 -0000 Received: (qmail 12983 invoked by uid 500); 7 Sep 1999 23:00:19 -0000 Date: Tue, 7 Sep 1999 16:00:19 -0700 (PDT) From: Dean Gaudet To: new-httpd@apache.org Subject: memory allocation (was Re: Why bother with APR?) In-Reply-To: Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org so i'm thinking that it may not be possible to decide ahead of time what type of memory allocation should be associated with a particular pool. that is to say -- some users of a pool may want palloc-style allocation, which isn't freed until pool destruction, and other users may want malloc/free style which can be freed at will. there's two reasons i'm thinking along these lines -- the first is that some users of a pool may be a cache, and could be hidden behind a library interface. the second reason is that i don't like lots of conditionals ;) i think of a pool as really a place to store cleanups. in essence, a pool could just be a list of cleanups. then ap_palloc() would register a cleanup the first time it is used. and ap_malloc() could register a cleanup for the list of malloc/free allocations. and ap_shmalloc() could register a cleanup for the shared mem allocations... this way the same pool can be used for any combination of the three types of allocations (and other allocations) without knowing ahead of time what style of pool it is. Dean