Re: attn: ghudson; FSFS and multi-threading on Unix broken?

I'm confused. APR already has the ability to have a per-thread lock.
I believe it is called a global_lock. The way this is implemented
depends on the platform, but for Linux I am pretty sure it is a fcntl
lock for inter-process and a pthread lock for intra-process. For AIX,
it is a cross-process pthread lock.

There was a lock of work done in APR to allow the global lock code to
work properly on all platforms, so SVN should probably just migrate to
that API.

Ryan

On Apr 5, 2005 11:12 AM, Greg Hudson <ghudson@mit.edu> wrote:
> 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
>
>

-- 
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org