Hey
>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.
>
woooo wait a minute. I'm not talking about creating a whole slew of
memory management.
I'm talking about creating a scratch pool usage paradigm re-enforced
with a little helper code. gat: hands a waving sounds like a frustrated
politician:-)
The code involved is mostly just one or two LOC for each comment.
Scratch pools can have an inconsistent memory foot print. If callers
assume a degree of encapsulation callers must also assume that what is
true today in the called function may not be true tomorrow (with respect
to scratch). The callee's "scratch" memory usage is less easily
predicted over time because it is internal to him.
Now toss in a situation where you have vtables down below. Now memory
usage can change based on configuration even run-time configuration.
All, I'm adding is a little accounting. Very little.
Here's the cool part. If you choose to simply use the
trail->scratchpool nothing bad happens. The accounting part can be
inserted anywhere into a existing scratchpool (subpool stack). As long
as you follow the push must pop rule. You will have a couple unused
ints in the trail structure.
> 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.
>
>
I'm cool with this.
I IMHO adding the pool to the function arguments is less flexible.
Even without what I proposed, I prefer to use just use the
trail->scratchpool.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 1 22:38:29 2002