On Thu, Feb 21, 2002 at 10:40:00AM -0500, Greg Hudson wrote:
> 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.
Yup, but many editors are not doing that. I keep running into them. The
trace editor, the composition editor, ra_dav has one or two, etc.
> > 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 new interface makes it easier for the editors to Do It Right. Currently,
all the editor implementations must deal with the subpool stuff, or else
they will be doing it wrong.
Essentially, it encodes the memory "policy" into the interface, rather than
just hoping that editors will get it right.
> The problem lies with the ra_dav commit editor, not
> with the interface.
That one, plus numerous others. The 12 meg that I was referring to was over
ra_local, not ra_dav.
> The old interface (with the proper discipline)
Key phrase: "with the proper discipline" :-)
I'm thinking that encoding the discipline into the interface will get us
away from this problem permanently.
> 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.
Well, the lifetimes are managed by the editor driver in both cases. In one,
it is done through explicit close_* calls. In the other, through pool
destruction.
> > * 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?
IMO, it simplifies the interface. The editor driver doesn't have to worry
about calling the function *and* tossing the pool. It just does one, and
*if* an editor cares about the close, then it has a well-defined way to hook
it.
> 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.
It can definitely be assumed that the pools will be tossed in a nested
fashion. That is part of the interface, and using cleanups is explicitly
provided.
I don't see any issue with the XML, the control points are named a bit
different, but are still there.
> Which isn't kosher; pool management
> should be about memory, not about deliberately invoking cleanup
> handlers.
Pools are more than just management. Cleanups and "user data" are two
additional facilities of pools. Memory management and cleanups are all about
lifetimes. Lifetimes of data mostly (the allocations), but also lifetimes
for other controls.
I'm totally fine with using a pool cleanups as control points. But if people
wouldn't mind doing *both* a close_FOO and a pool destroy, then we could
keep the close functions.
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
Received on Sat Oct 21 14:37:09 2006