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