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

Re: svn commit: r40218 - trunk/subversion/svn

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Mon, 26 Oct 2009 22:05:52 +0100

On Oct 26, 2009, at 4:31 PM, Greg Stein wrote:

> On Mon, Oct 26, 2009 at 04:32, Julian Foad
> <julianfoad_at_btopenworld.com> wrote:
>> Greg Stein wrote:
>>> On Sat, Oct 24, 2009 at 18:42, Julian Foad <julianfoad_at_btopenworld.com
>>> > wrote:
>>>> Greg Stein wrote:
>>>>> If you construct the iterpool in the declaration (as before),
>>>>> then you
>>>>> can use it for the call to svn_cl__xml_print_header(), as its
>>>>> scratch_pool. Any mem used by the call will be cleared on the
>>>>> first
>>>>> iteration of the loop.
>> [...]
>>>>> And if you don't destroy it so soon, then you get to use it for
>>>>> that
>>>>> last call, too.
>>>> [...]
>>>> That's true, there is the opportunity to do that, but is it
>>>> really worth
>>>> breaking the well-defined "iterpool" pattern for such a little
>>>> extra
>>>> optimisation? I don't think so. Keep it simple.
>>> Eh? How does it break it?
>>> You alloc the iterpool. clear it at the start of each iteration.
>>> destroy it later. I see no change to that.
>> "The pool you use also helps readers of the code understand object
>> lifetimes. Is a given object used only during one iteration of the
>> loop,
>> or will it need to last beyond the end of the loop?"
>> Quoted from <http://subversion.tigris.org/hacking.html#apr-pools>.
> Okay. So what? The iterpool is still an iterpool, used within the loop
> and cleared each time. How does allocating other objects in it "break"
> the pattern?
> (and yes, we use iterpools outside of the loop in plenty of other
> places; it makes a great scratch pool)

But if we already have a scratch_pool, why use the iterpool? *Both*
are going to be cleared Real Soon Now, and using the scratch_pool
(over the iterpool) fits better with our pool usage semantics.


Received on 2009-10-26 22:06:21 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.