D.J. Heap wrote:
>On Sun, 2005-04-03 at 09:21 -0600, D.J. Heap wrote:
>[snip]
>
>
>>It seems like allowing the same process to re-lock could be bad for
>>threaded programs like svnserve/mod_dav_svn, but maybe threads count as
>>different processes on Unix?
>>
>>BDB obviously does not fail because it doesn't do locking this way, but
>>what does 'exclusive repo write lock' mean to it?
>>
>>DJ
>>
>>
>
>I checked the docs for apr_file_lock:
>
>"Establish a lock on the specified, open file. The lock may be advisory
>or mandatory, at the discretion of the platform. The lock applies to the
>file as a whole, rather than a specific range. Locks are established on
>a per-thread/process basis; a second lock by the same thread will not
>block."
>
>This is not how it behaves on Win32 with the way it uses LockFileEx.
>
>So, this appears to be an apr problem on Win32. I will investigate how
>to make apr behave as documented on Win32, but probably Subversion will
>need a workaround at least for a while.
>
>Any thoughts on a workaround? Only this one series of tests seems to be
>a problem because of the way it shares the pool...perhaps the test could
>be modified temporarily?
>
>
I'd say that an exclusive lock is an exclusive lock. If the pool that
"owns" the lock doesn't get cleared on error, then that's a bug. And a
good thing that Windows exposes it.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 22:13:30 2005