On Thu, 9 Sep 2004, Greg Hudson wrote:
> On Thu, 2004-09-09 at 14:53, Peter N. Lundblad wrote:
> It took me a while to figure out why we need a private subpool (it's
> because we need to make allocations in that subpool in order to create
> new handles, and allocations within a pool aren't thread-safe). You
> might make the comment a little more verbose.
>
Always a good reason to extend a comment.
> + /* If we are called from inside a pool cleanup handler, the just created
> + xlate handle will be closed when that handler returns by a newly
> + registered cleanup handler, however, the handle is still cached by us.
>
> I don't understand this. We allocate the xlate handle in the pool
> created by svn_utf_initialize(), right? And presumably *that* pool has
> no cleanup handlers which invoke translation functions, since we own the
> pool. So why would the cleanup handler fire off right away?
>
This happens when the global cache isn't used anymore and therefore the
per-pool cache is used. Then if we create a handle in a clean-up function,
right after that, the handle will be closed and the next cleanup function
that needs a handle will crash. You can try it if you want to. Just remove
this part and try svnversion in a directory with subdirectories. Also,
remember that a pool will run its own cleanups first, then the subpool
cleanups. So, if we have subpool with cleanups that do char xlations and
they are cleaned up by the global pool that was passed to
svn_utf_initialize, our cache will be destroyed before thos subpool
cleanups are called and the per-pool cache will be used, but not in many
cases, since the handles will be closed after each cleanup. I think we
have this problem in the old code too. We've just been lucky that a handle
was created earlier in this case when the per-pool cache was used all the
time.
This is messy. Hope I expressed my self somewhat clearly...
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 9 21:55:18 2004