On Tue, 5 Apr 2005, Greg Hudson wrote:
> On Tue, 2005-04-05 at 15:21, Peter N. Lundblad wrote:
> Because this problem could affect anyone using a DAV server on Unix, I
> don't think we can defer the problem to APR. Also, since APR has built
> this global mutex thing which looks like a solution but isn't, they
> might be resistant to adding yet another inter-process/inter-thread
> locking mechanism. So we'll need to do something in Subversion,
> probably along the lines of an svn_fs_initialize like you suggested.
>
> Unlike the situation with UTF-8, if we don't get an svn_fs_initialize()
> call, we can't sacrifice performance for correctness as far as I know.
> But, we can make a best effort:
>
> if (!static_variable) {
> static_variable = 1;
> create static_mutex;
> }
>
> If this seems bad, note that this is how neon protects SSL
> initialization. The window of failure is very small. And, of course,
> if you do call svn_fs_initialize before going threaded, it would create
> the mutex and set the variable and there would be no failure window.
>
Yeah, this is ugly, but maybe it is acceptable to be pragmatic here. We've
gone through this initialization once stuff before.
> Do we have a way of calling svn_fs_initialize from mod_dav_svn? We
> don't seem to call svn_utf_initialize there.
>
Someone who knows about apache could probably say something here. Not sure
if dav_svn_init qualifies. "Called once in a single threaded environment."
A problem with this fix is that it won't be trivial. So it might be risky
for 1.2. OTOH, as yoiu point out, we want it in 1.2 also.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 6 19:16:46 2005