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

Re: ra_svn and thread-safety/initialization

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-06-01 08:01:04 CEST

On Sun, 2003-06-01 at 01:52, rbb@rkbloom.net wrote:
> Two things. 1) APR not having a static initializer that you can use is a
> pretty major bug that makes apr_thread_once a lot less useful. It's my
> fault, I wrote the function originally, and I didn't think that through.
> It should be a relatively easy patch to create one. That would be one way
> to resolve the problem.

On Unix, apr can use PTHREAD_ONCE_INIT. On win32, it looks like apr can
use all-zeros. On OS2, it looks trickier.

> 2) I haven't read the ra_svn code, so I am just spitballing here, but
> there must be some place that you can call apr_thread_once_init before
> you create threads. If there isn't, then you will need to modify APR to
> include a static initializer.

Right now, Subversion does not have a library initialization function.
And ra_svn is supposed to be absolutely invisible to the application (it
hides beneath the covers of libsvn_ra), so there's no way I can demand
that applications call some special ra_svn initializer before creating
threads.

We can certainly change the lack of a library initializer, but I'm not
certain it's a great idea. It was one of the options I presented in my
initial mail.

> Right now I feel like a moron for leaving that out. I wonder how many
> other places need a static initializer that I didn't think about.

Mutexes and condition variables traditionally have static initializers
(they do in POSIX.4, anyway), but I don't know if all of APR's target
platforms make them possible.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 1 08:01:53 2003

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.