Return-Path: 
 <dev-return-10097-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 68398 invoked by uid 500); 10 Jul 2003 22:16:16 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 68381 invoked from network); 10 Jul 2003 22:16:16 -0000
From: Joshua Moore-Oliva <josh@chatgris.com>
To: Cliff Woolley <jwoolley@virginia.edu>
Subject: Re: Bug Report -- sorry if duplicate my first attempt at sending my
 email was not working.
Date: Thu, 10 Jul 2003 18:15:05 -0400
User-Agent: KMail/1.5.2
Cc: dev@apr.apache.org
References: <200307101745.45537.josh@chatgris.com>
 <Pine.GSO.4.53.0307101757250.4187@cobra.cs.Virginia.EDU>
In-Reply-To: <Pine.GSO.4.53.0307101757250.4187@cobra.cs.Virginia.EDU>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200307101815.05390.josh@chatgris.com>
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at
 fep01-mail.bloor.is.net.cable.rogers.com from [24.157.135.21] using ID
 <janetteoliva@rogers.com> at Thu, 10 Jul 2003 18:16:13 -0400
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

<snip>
> All you have to do is get rid of those two apr_pool_destroy() lines and it
> will work fine.  You can go ahead and free(t) in your cleanup function.
> Then when you cleanup "pool", read_pool and write_pool will be cleaned up
> and then t will be freed.
>
> The point is that you should never register a cleanup in a parent pool
> that calls apr_pool_destroy() on a child pool.  It's already done
> implicitly.

I do understand that it is done implicitly.  However, I do believe that this 
small change should be done. So I shall state my case and be done with it. 
(this is all IMHO, you guys have a great project )

Regardless of it's usefulness, it is something that people can do.  I do not 
see any performance penalty by running the cleanups before clearing the 
subpools, and it eliminates a possible segmentation fault.  Why leave 
something in the code that can be a trip-up when there is no reason to 
eliminate the possible bug in another persons program? (saying that the bug 
is technically in the persons program, but why allow there to be a bug at 
all? )

Anyways, I have changed my code to work with the current design.

Josh.