Received: by taz.hyperreal.com (8.6.12/8.6.5) id KAA05270; Wed, 8 May 1996 10:52:12 -0700 Received: from madhaus.utcs.utoronto.ca by taz.hyperreal.com (8.6.12/8.6.5) with ESMTP id KAA05262; Wed, 8 May 1996 10:52:07 -0700 From: rasmus@madhaus.utcs.utoronto.ca Received: from rathaus (rathaus [128.100.102.12]) by madhaus.utcs.utoronto.ca (8.7.4/8.7.1) with SMTP id NAA15758 for ; Wed, 8 May 1996 13:51:45 -0400 (EDT) Date: Wed, 8 May 1996 13:51:45 -0400 (EDT) Subject: Re: Memory Pool Management Question To: new-httpd@hyperreal.com In-Reply-To: <199605081724.NAA11900@volterra.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com > The solution, of course, is not to get into that situation --- either > by judicious creation and destruction of sub-pools (perhaps on the model > of what goes on in mod_dir.c), or by explicit invocation of malloc() and > avoidance of hard timeouts. If I go the sub-pool route, can I assume that if a hard timeout occurs before I get around to calling destroy_pool() on my sub-pool that it will still get cleaned up? I only see a call to bclose() in the timeout() function and nothing that says to go and clean up any stray sub-pools.. But I haven't looked extremely closely yet. -Rasmus