On Wed, 10 Jan 2007, Ivan Zhakov wrote:
> On 1/10/07, Daniel Rall <dlr@collab.net> wrote:
> >On Wed, 10 Jan 2007, Hyrum K. Wright wrote:
> >
> >> Malcolm Rowe wrote:
> >> > On Wed, Jan 10, 2007 at 09:05:25AM -0800, hwright@tigris.org wrote:
> >> >> Log:
> >> >> Use a subpool for copy and move operations. If the copy or move
> >fails, and the
> >> >> *_as_child flag is set, we try again. By adding this subpool, we
> >make sure
> >> >> that the memory from the first try (as well as the second) is cleared.
> >> >>
> >> >
> >> > That's not a typical use of a subpool, unless we have reason to believe
> >> > that the setup_copy() operation will allocate a significant amount of
> >> > memory.
> >>
> >> I don't have any figures, and I'm not sure what the threshold is for "a
> >> significant amount", but my feeling is that the amount of memory isn't
> >> trivial.
> >>
> >> If this is wrong, though, I'm happy to revert.
> >
> >Will setup_copy() allocate a potentially unbounded number of data
> >structures (e.g. svn_client_commit_item3_t's)? If so, use of a
> >subpool seems reasonable here.
> >
> I think setup_copy() should care about subpool in this case.
We can't use an iterpool or subpool inside setup_copy(), since we
return some of these data structures from setup_copy(). So, we have
to pass a pool in.
- application/pgp-signature attachment: stored
Received on Wed Jan 10 19:03:36 2007