On Wed, Jan 10, 2007 at 11:54:33AM -0600, Hyrum K. Wright wrote:
> >>> 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.
>
> Yes. There are several data structures (depending on the mode) which
> could be allocated an unbound number of times.
>
Sounds like a sensible change then. Sorry for asking, I was just
surprised not to see setup_copy() manage those allocations itself (which,
as Dan points out, would be hard as we need to ensure that they're passed
back to the caller).
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Wed Jan 10 19:27:54 2007