On Sun, 2004-08-15 at 16:41, Peter N. Lundblad wrote:
> But the apr_pool_userdata_{get,set} isn't thread-safe just because we
> protect our uses by a lock. Other callers don't.
Right, sorry. I was imagining our specific userdata slot could be
protected this way, but of course it can't.
> I don't see a way to improve the performance via caching in pools. If we
> want to fix this, I think we need to add init functions and be able to
> detect if they were called. If this is problematic for 1.1 ( to which I
> might agree), then we won't fix this until 1.2. This will hurt TSVN users
> I think and that's bad because that's an important application on Windows.
I agree that we should solve this problem for 1.1, even at a high cost.
Let's introduce an optional initializer, but let's make it very limited
and specific. "void svn_utf_initialize(void);". We acknowledge that
it's a short-term hack. It can become a no-op in 1.x and can disappear
in 2.0.
I can think of three long-term solutions to free ourselves from this
hack:
* Add a more general library initialization framework for this sort of
thing.
* Invent the notion of a Subversion library context, like the
libsvn_client context but more opaque and general, and pass a library
context around to most or all svn library functions. This is the
"cleanest" solution, but it's also burdensome; callers already have to
pass around pools and exceptions. (We could fold the pools and/or the
exceptions into the library context to reduce the burden, but I'm not
sure that idea really pans out.)
* Teach APR to handle statically-initialized onces.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 15 23:43:07 2004