Re: svn commit: rev 3215

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> Philip, I tweaked this log message to name the correct function, and

Thanks!

> The caller `pool' is now only used twice in the function, once at the
> top:
>
> /* Load PATH's whole entries file. */
> SVN_ERR (svn_wc_entries_read (&entries, adm_access, TRUE, pool));

This function uses the access baton pool to read the entries file, and
to allocate the ENTRIES hash. The POOL parameter is only for local
stuff, errors, etc.

> and once at the bottom:
>
> /* Sync changes to disk. */
> SVN_ERR (svn_wc__entries_write (entries, adm_access, pool));

It's important not to use the access baton pool here, we don't want
the buffered text of the entries file allocated from that pool (doing
so was main cause of the abysmal memory usage).

> In between, every function that needs a pool is getting
>
> svn_wc_adm_access_pool (adm_access)
>
> as its pool argument, even though none of those functions take
> `adm_access' itself. So I'm wondering, why don't those calls, or at
> least some of those calls, just take `pool' as well? (In other words,
> why didn't you just leave the text "pool" for those calls, which after
> your change to the top of the function would now refer to the caller
> pool instead of the access baton pool?)

Um, would you believe "laziness" :)

I've been passing these access batons around for so long without
getting much benefit, I was keen to see something more concrete, and
simply changing the pools was a quick-n-dirty solution.

What needs to be achieved is that the access baton pool is used for
everything that is referenced by the hash of entries, otherwise the
cache will become outdated. It looks like fold_scheduling doesn't
need to be passed the access baton pool, since the pool is only used
for errors. On the other hand fold_entry does use its pool for
allocations, so for the cache to work these allocations must occur
from the access baton pool.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org