On Tue, 2005-04-05 at 05:46, Peter N. Lundblad wrote:
> As you see, I haven't fleshed out the resolution proposal very much. But I
> want people to be aware of the possibility that we have a serious FSFS
> (dataloss?) bug. Please someone (ghudson?), tell me that this is a false
> alarm! :-)
I don't think it's a false alarm. But as you noted, it's rare to use
svnserve in threaded mode under Unix. Under Windows, we know you can
block against a lock you already hold (see recent deadlock issues), so
locks are effectively per-thread. And I think it's currently unheard of
for a third-party multithreaded Unix program to be interested in more
than the network client part of the Subversion libraries.
I would like to see the fix happen in APR. Subversion is not unusual in
desiring a per-thread file lock; I know krb5 has run into this issue as
well. And APR already has an initialization function, so it doesn't
have that problem.
One option for the new APR interface is simply a lock which is
guaranteed to block even if the lock is already held within the current
process--that is, the Windows apr_file_lock() behavior, but on all
platforms. A more complex notion would be to create the idea of a
locking context; the new lock interface would not block the current
thread if the lock is held within the given locking context (it would
act as a recursive lock), but would block if the lock is held within a
different context in the same thread. You can see how this would be
nice for the FSFS locking code--no more "I already have the lock" flag
for lock auto-expiry--but it's arguably doing too much of the
application's job within the APR library.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 5 17:19:29 2005