Ruediger Pluem wrote:
Nevertheless I think that the precleanup code in apr trunk and the changes to the reslist in apr-util trunk are not backportable just because of the example above: Code may break if you change an apr / apr-util 1.3 release under the hood. This should not happen.
I agree with you. However, like you observed this particular apr_reslist usage was simply presuming the reslist was not already destroyed, by doing nasty tricks and registering additional cleanup on top of existing one so that we can mark the structure (worker->cp->pool = NULL) element before calling apr_reslist_destroy so that destructor callback knows their child pools have been already destroyed, so it doesn't destroy them twice, and still allows connection pool mix...max maintenance where the child pools has to be explicitly destroyed so that memory doesn't leak. All that is a total mess and hard to follow. With pre_cleanup, the code is simpler and straightforward: constructors creates, desctructor destroys, and that's it :) Anyhow, porting that to 1.3 would probably break (presumption) of the 'under the hood' behavior (not the API itself). Regards -- ^(TM)
