[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Destroy the APR subpool before every successful returnstatement

From: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2007-01-08 04:18:41 CET

Erik Huelsmann wrote:
> On 1/7/07, Branko �ibej <brane@xbc.nu> wrote:
>> Bhuvaneswaran Arumugam wrote:
>> > Hello,
>> >
>> > Please find attached the patch. If this is a valid patch, i'd like to
>> > prepare similar clean-up patch for remaining files under
>> > subversion/libsvn_client directory.
>> >
>> The whole point of using pools is that you don't have to deallocate
>> stuff (that's known to be size-bound). So no, this is not a valid patch.
>> It just messes up the code without actually gaining much.
> Yes it is. If we were not intending to destroy the memory, why use a
> subpool at all?
> Non-destruction of pools is valid when returning *in the error-case*,
> because we assume that the error will be handled and a parent pool
> will be cleared somewhere higher up the call chain. But for the
> non-error return, we neither assume nor actually do something like it

I guess this depends on the expected code behavior - for long-lived parent
pools then we really should (must) clean up. This is also very true of
code that may make multiple trips up and down the API/call stack. Memory
usage would grow as the call fanout grows.

Good practice is always to clean up - using pools makes it easier since
you only need to clean the pool and not all of the individual allocations.
However, the pool system does not replace actual cleanup - this is not
a GC type solution.

Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 8 04:19:21 2007

This is an archived mail posted to the Subversion Dev mailing list.