On Tue, 2005-04-05 at 15:21, Peter N. Lundblad wrote:
> But won't we have the same initialization problems as I scetched in my
> original mail? A global_mutex creates a thread mutex internally, so you
> hae to use the same global_mutex for each thread for this to work.
You're right; the solution isn't as simple as I thought. I was
imagining that APR's global mutexes were really "global" like the name
implies--that the provided pathname identifies a lock within a namespace
common to all threads and processes. But it doesn't work like that; the
pathname is only used for inter-process locking and is only used by some
inter-process locking mechanisms.
> Then,
> is there really a benefit to using this global_mutex instead of just
> wrapping the apr_lock_file with locking/unlocking a mutex with thread
> scope?
Probably not much of one, since we can't use a global mutex on Windows.
So, my revised position:
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.
Do we have a way of calling svn_fs_initialize from mod_dav_svn? We
don't seem to call svn_utf_initialize there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 6 18:56:56 2005