[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_utf_initialize and pool cleanup

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-09-07 22:10:18 CEST

On Mon, 6 Sep 2004, Greg Hudson wrote:

> The signature of our UTF-8 initialization hack is:
>
> void svn_utf_initialize (void)
>
> Peter initially had it take a pool argument, but then changed it to
> allocate a subpool of the global pool, and made it clean up the xlate
> handle at apr_terminate() time.
>
> My concern here is that if someone dynamically loads the Subversion
> libraries and then unloads them, this pool will be leaked each time
> (unless the application initializes and terminates APR on each load,
> but that's not a fair assumption to make, since the application might
> be using APR for other reasons).
>
> So I do think we want to be passing a pool argument to
> svn_utf_initialize(), with the proviso that no Subversion functions
> may be in progress when this pool is cleaned up. The pool cleanup
> handler can reset the static data so that we go back to per-pool xlate
> handles.
>
OK. I didn't think of that scenario at all. I think that change is
straightforward. I wanted to simplify things by handling the cleanup
internally, and since we need to create a subpool for our private use
(protected by the mutex), I just removed the the pool argument.

> Speaking of which, it looks like Peter's code doesn't use per-pool
> xlate handles when svn_utf_initialize() is called, which means his
> change makes translation much *slower* if the initializer isn't
> called. That doesn't seem acceptable.
>
You're right. It's a regression if you don't use the init function. I'll
readd that caching.

I'll look at these ASAP, hopefully meaning this week.

Still I don't like to rush in this change this late in the release
process. IMO it has to wait until 1.1.1 since it needs more testing on
differet platforms in applications that actually are multi-threaded.

Thanks for the comments, Greg
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 7 21:56:11 2004

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.