[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Win32 Tests -- locks-test

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2005-04-03 22:09:16 CEST

D.J. Heap wrote:

>On Sun, 2005-04-03 at 09:21 -0600, D.J. Heap wrote:
>>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?
>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
>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

This is an archived mail posted to the Subversion Dev mailing list.