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

On Fri, Nov 01, 2002 at 02:34:05PM -0600, Ben Collins-Sussman wrote:
>...
> 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.

The two points above do not need to be serialized. You could add a new param
to a function for the scratch data, and just ignore trail->scratchpool. This
might actually be somewhat ideal for functions that have very few callers.
The funcs with a *large* number of callers... well, maybe they stick with
the trail->scratchpool :-)

Note: I might suggest that you identify the most problematic functions and
deal with those first. I don't know an easy way to do that, however.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org