Greg Stein <gstein@lyra.org> writes:
> I believe the main thrust is to add pools to FS function arguments, rather
> than using internal pools.
Well, all the FS functions take pools already. There's no case where
we use an object's pool for per-operation allocation; that would be an
obvious botch.
The only thing that needs to happen to the public interface, I think,
is to delete the `close' functions:
svn_error_t *svn_fs_close_fs (svn_fs_t *fs);
svn_error_t *svn_fs_close_txn (svn_fs_txn_t *txn);
void svn_fs_close_root (svn_fs_root_t *root);
If those functions don't exist, then filesystems, transactions, and
roots don't need per-object subpools. The only drawback is that,
since we're letting the pool cleanup functions do the finalization, we
can't really return full Subversion error codes.
But to recap the argument made before --- here's why we shouldn't make
per-object subpools:
The sole advantage per-object subpools provide (ignoring the error-
returning issue mentioned above) is the ability to free the object
before you free its parent pool. (You might think that a `close'
function is necessary for cleanup actions for the object --- closing
files, releasing DB resources, etc. --- but you could get the same
effect by registering a cleanup function with the parent pool.) If
you're going to leave cleanup to the pool, instead of calling the
`close' functions explicitly --- a fine approach --- then the
per-object subpools are useless to you.
Note, then, that the caller could get the same benefit simply by
creating a subpool itself, and allocating the object in that subpool.
There's no additional flexibility gained by having libsvn_fs create
subpools for you.
Finally, note that the only time you really need to free objects early
is when you're in a loop or recursion, where the number of steps to be
performed depends on the data (walking a tree; processing a file's
contents; anything, basically). In these cases, you should create a
pool at the start of each iteration, do the body of the loop, and then
free the pool at the end of the iteration. That way, each iteration
doesn't leave dead objects behind. In these cases, per-object
subpools are a waste --- they're subpools of the per-iteration pools,
and will die exactly when their parents do. Useless.
So, in summary, per-object pools are either useless, or useless.
Per-iteration pools are where it's at.
Received on Sat Oct 21 14:36:26 2006