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

"Glenn A. Thompson" <gthompson@cdr.net> writes:

> It seems to me that managing memory is a good function for trails. So
> why not add some methods on trail_t to manage scratch pools?

gat, you make an interesting proposal.

But if you're going to go and create a whole slew of memory-management
funcs for trails, well, I think it's just easier to have the pools
passed explicitly, and allow callers to manage/clear them as they're
supposed to in the first place. We already *have* pool management
routines to some degree... I'd rather not implement finer-grained
versions that only exist in trails, especially when people are
uncomfortable with pools living inside trails for the long run.

I think the best plan of attack is this:

  1. Slowly, carefully teach the dag routines how to use two pools.
     For now, this means using trail->pool and trail->scratchpool. As
     we convert each routine, our memory footprint will get better and
     better.

  2. When every routine has been converted, then we make the next 'big
     step' by passing the pools explicitly as arguments. At that
     point, callers will have as much control as they wish over memory
     management.

If nobody objects, I'm starting work on #1.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 1 21:35:47 2002