[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: Greg Stein <gstein_at_gmail.com>
Date: Mon, 26 Oct 2009 11:31:28 -0400

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)

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2411432
Received on 2009-10-26 17:28:15 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.