Re: Sub-pools for recursion
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-11-28 15:35:55 CET
Julian Foad wrote:
Actually, I see now that the sub-pool in this function is serving double duty as a recursion sub-pool and as an iteration sub-pool. This complicates the situation.
As this sub-pool is cleared after each iteration, it cannot be used for data which must live throughout the function, and that is why the passed-in super-pool, "pool", is used for the adm. access. But it can be and is being used for temporary things before the loop begins, as well as for temporary stuff within the loop.
Should the sub-pool be reserved for either one purpose or the other? If so, should we introduce a second sub-pool for the other purpose, as I think is done elsewhere? In practice, there is probably not a great deal of memory being used here, but I would like to determine a "best practice".
Since the recursive call is made from within the iteration, there is really no need for a separate recursion sub-pool in this case, so I think this function should regard its sub-pool as an iteration sub-pool. Everything that is not local to the iteration should be allocated in the passed-in "pool". Does that sound right?
I believe there are definite mis-uses of both "pool" and "sub-pool" in the function. Here is an abbreviated and annotated version of the function; all comments are mine:
copy_versioned_files (..., apr_pool_t *pool)
SVN_ERR (svn_wc_adm_probe_open (..., pool)); /* OK: needed throughout */
if (entry)
SVN_ERR (svn_io_get_dirents (&dirents, ..., pool)); /* OK: needed throughout */
for (hi = apr_hash_first (pool, dirents); hi; hi = apr_hash_next (hi))
- Julian
---------------------------------------------------------------------
|
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.