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

On Thu, Oct 31, 2002 at 09:13:01PM -0500, Greg Hudson wrote:
> On Thu, 2002-10-31 at 18:29, sussman@tigris.org wrote:
> > * trail.h (struct trail_t): add new 'scratchpool' to trail.
>
> This is undoubtedly an improvement, but passing around pool parameters
> would still be better.

Absolutely agreed. Ben and I talked about that as Yet Another Future
Improvement. He just didn't mention it in his email.

>...
> If we were passing around pool parameters, you'd have the third and most
> preferrable option:
>
> * Use the pool you were passed, and let the caller decide whether
> that's a temporary subpool.

Yup. I do think we want to keep the dual-pool concept, though.

> I think in general, we should never assume that a function can use a
> pool stashed somewhere in a baton for temporary allocations; we should
> always pass one in.

You bet. It is rather difficult to do "iteration subpool" types of usage
because you have to "reach into" the trail structure.

Actually, my example to Ben was regarding the result pool. If you have a
function that wants a result for some intermediate purpose, then it has to
reach into the trail structure, tweak the result pool, call the target
function, then change the trail back. This really breaks some of the
encapsulation (if you will) of the trail structure.

The same issue applies to the scratch pool.

> (The editor interface sometimes doesn't pass in a
> pool because it knows the stashed pool will only be usd once; I think
> that was a mistake, just in terms of consistency, but it has no
> practical problems.)

In retrospect, yah. It was a definite improvement to add the pool
parameters, but I should have added the pool to more of the calls. I seem
to recall a situation where it actually would have been good to pass a pool
to the apply_textdelta or close_foo or whatever it was; I can't
remember/imagine why that was the case, which is why the pool *isn't*
passed in the first place, but I think there was one.

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