On Tue, 2004-12-14 at 19:25, Julian Foad wrote:
> VK Sameer wrote:
> >>>--- subversion/libsvn_wc/update_editor.c (revision 12257)
> >>>+++ subversion/libsvn_wc/update_editor.c (working copy)
> >>>@@ -1431,10 +1432,12 @@
> >>> const svn_wc_entry_t *entry;
> >>> svn_node_kind_t kind;
> >>> svn_wc_adm_access_t *adm_access;
> >>>+ apr_pool_t *subpool;
> >>>
> >>> /* the file_pool can stick around for a *long* time, so we want to use
> >>> a subpool for any temporary allocations. */
> >>>- apr_pool_t *subpool = svn_pool_create (pool);
> >>>+ subpool = svn_pool_create (pool);
> >>>+ SVN_ERR (svn_path_check_valid (path, subpool));
> >
> > Sorry, I meant to use pool instead. The thought was that this would
> > avoid increasing memory usage just before erroring out. Updated in
> > patch.
>
> It is not appropriate to optimise for reduced memory usage in the error
> condition, since
> + the error condition is the rare case;
> + it was only a small allocation, and one which would have been made in the
> common case anyway;
> + the pool memory will get freed soon enough, regardless of which way you do it.
Doesn't svn_destroy_pool (subpool) have to be called to free the
subpool? If so, I don't see how subpool memory would get freed if
SVN_ERR causes a jump out of add_or_open_file().
> The existing comment explains why we want to use a sub-pool: you saved memory
> in the error condition at the expense of potentially using extra memory in the
> file's main pool for every successful open, and that pool may persist for a
> long time.
True, I didn't consider that.
Regards
Sameer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 02:05:22 2004