On Wed, 2004-12-15 at 17:23, Julian Foad wrote:
> VK Sameer wrote:
> > On Wed, 2004-12-15 at 06:41, Garrett Rooney wrote:
> >
> >>Pools are hierarchical, if you don't destroy the subpool it will get
> >>cleaned up when its parent pool is eventually destroyed.
> >
> > OK, that's good to know. I guess I don't see the point of relying on
> > that when I can just re-use an existing pool.
>
> Sorry, I don't follow that sentence. Do you mean "... when I can use a
> sub-pool that is explicitly destroyed within this function"?
No, I meant use 'pool' instead of 'subpool' which gets destroyed at
'pool'-destruction time.
> Note that your new statement is not the only error return from this function.
> There is no point in making your new statement destroy the sub-pool and leaving
> all of the existing error returns as they are. Therefore there is no need for
> this change to be part of this patch: it is a separate change.
Yes, that was the major point I missed. Karl and Fitz mentioned that in
IRC as well. Given that, I'll put the initialization back to how it was.
> This is a reasonable way of handling the situation, though a little fragile. A
> more robust way is to wrap the function in a subpool-handler function that
> creates and destroys the subpool, but that usually feels too cumbersome. I
> think the "goto" method is the most appropriate here.
I've still got the "don't use goto" hangup, though it's slowly dying
away :). It makes perfect sense in this scenario, though.
Thanks for the detailed explanation.
Regards
Sameer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 16 05:06:08 2004