Re: svn commit: rev 3598 - trunk/subversion/libsvn_fs

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> Greg Hudson <ghudson@MIT.EDU> writes:
> > * Use a subpool of trail->scratchpool and destroy it. We like to
> > discourage this except for unbounded loops, because pools are considered
> > fairly heavyweight objects.
> >
> > * Use trail->scratchpool itself, and hope you don't get called too
> > many times.
>
> But wouldn't the caller take care of it, then?
>
> That is, why can't users -- caller and callee -- of trail->scratchpool
> treat it just the way they would treat a separate pool argument?

That's what I was thinking.

I mean, right now, trail->scratchpool is created in begin_txn() and
destroyed in commit_txn().

But the top of trail.c is a very cozy, small world. It would hardly
be any different if retry_txn() were responsible for creating and
destroying trail->scratchpool instead. It could clear the pool on
each retry.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 1 13:46:02 2002