apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Moore-Oliva <j...@chatgris.com>
Subject Re: Bug Report -- sorry if duplicate my first attempt at sending my email was not working.
Date Thu, 10 Jul 2003 22:15:05 GMT
> 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.


View raw message