Philip Martin <philip@codematters.co.uk> writes:
> 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.
Gotcha. It sounds like we'll need some conventions for documenting
pool behavior for functions that take access batons, or that take
objects allocated from (or together with) access batons.
To fix up svn_wc__entry_modify(), it sounds like
* svn_wc_entries_read() must document what it allocates in the
access baton pool vs what it allocates in its other pool,
* fold_scheduling() must promises to only use its pool for errors.
Currently, it doesn't document its pool argument at all :-).
* fold_entry() will need to document that it can use pool to
allocate data it adds to entries. It also needs to document any
lifetime requirements of its `name' parameter. Depending on the
above, perhaps the allocation of `name' in svn_wc__entry_modify()
can just happen in `pool' right now...
Hmmm, this is complicated. Do you want me to file an issue, or is it
on your list anyway?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 24 17:28:34 2002