Greg Stein <gstein@lyra.org> writes:
> On Sat, Oct 14, 2000 at 04:46:58PM -0000, jimb@tigris.org wrote:
> > User: jimb
> > Date: 00/10/14 09:46:58
> >
> > Modified: subversion/libsvn_fs dir.c
> > Log:
> > libsvn_fs/dir.c (svn_fs_open_node): Be sure to close any nodes we've
> > opened in the process of descending the tree, even when we return an
> > error.
>
> Every time a node is opened, it *is* automatically registered with a pool,
> right? (to ensure that it gets cleaned up no matter what)
When you close a filesystem, the whole shebang goes away ---
everything it ever allocated, everything. So that level is okay.
Now, once you've got a node object, you can register it with a pool,
by calling svn_fs_cleanup_node. But there's no pool argument to
svn_fs_open_node, to automatically register it when you open it.
Is that good enough?
If we want to do better, there's another wrinkle here: if you open the
same node multiple times --- say, by walking down from different
versions' root directories to a node version that happens to appear in
all the filesystem versions --- you get a pointer to the *same*
in-memory object each time. The filesystem has a cache of node
objects that are currently open, so it can find nodes it has already
read in and just hand them to you. This seems nice, and should be
handy for some access patterns I suspect will be common.
Unfortunately, this makes it complicated to make node objects work
completely smoothly with pools. Ideally, you'd specify a pool when
you opened the node, and the node would get freed when you freed the
pool, or closed the node manually --- whichever happens first.
However, since the user could open a given node object several times,
and specify a different pool each time, it's no longer clear which
cleanup to run (or kill, whatever) when you close the node. The
`close' call would need a pool argument, so it could tell that pool
"never mind about this node". But passing a pool argument to `close',
and requiring the user to be sure they close the node in the same pool
they opened it in, seems clumsy.
So maybe I should just ditch the in-memory node cache. But I think
it's going to be pretty helpful. Or maybe I should have the `open'
call pass out a different object each time, which knows the pool it
was allocated in, but which references a shared representation of the
node's contents. But that's hairy.
Or maybe the status quo is okay.
Received on Sat Oct 21 14:36:11 2006