On Thu, 2002-02-21 at 10:22, Greg Stein wrote:
> Some initial investigation showed the standard culprit: file and dir batons
> allocated from a global(ish) pool, rather than subpools.
In our current discipline, editor batons are supposed to be
self-managing types, meaning they allocate themselves in a subpool (of
the parent baton's pool) and destroy the subpool upon close. This isn't
fashionable, but it does limit memory usage.
> To put this problem to a final rest, I've drafted a new editor interface.
It's not clear to me how this interface "puts the problem to a final
rest," but I'm fine with getting rid of self-managing types (for
consistency). The new interface doesn't really carry any advantages
over the old one as far as making it less likely for memory usage to
grow large; you have to create a subpool for each directory and for each
file either way. The problem lies with the ra_dav commit editor, not
with the interface.
The old interface (with the proper discipline) is actually a little nice
because pool usage is guaranteed to reflect the lifetime of the objects
being managed. Hopefully the new one won't present any problems in this
regard.
> * close_directory() and close_file() are omitted. Instead, register a
> cleanup with the pool that was passed at baton construction time.
What's the advantage here? This would totally screw the XML output
editor, for instance, unless you assume that the caller is doing pool
management in a very specific way. Which isn't kosher; pool management
should be about memory, not about deliberately invoking cleanup
handlers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006