<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.
