D.J. Heap wrote:
> I'm having trouble with Win32 tests on trunk -- locks-test.exe hangs
> with the following call stack:
[snip]
> Can someone else confirm/deny this result on Win32? Is apr_file_lock's
> 'exclusive lock' behavior semantically different on Unixes or is this
> test hanging on Linux also? I haven't deeply investigated yet, but will
> try to this weekend. It seems like it could be caused by a previous
> test function not cleaning everything, but that is just a guess.
>
> DJ
The problem seems to be (in fsfs repos only) that the subpool created by
fs_fs.c:svn_fs_fs__commit which holds the write lock is never cleared on
error conditions -- so the intentional failure on line 503 of
locks-test.c where we are 'nobody' orphans the write lock until the main
pool is cleared which doesn't happen until after all locks-test.c tests
are done.
Then the next locks-test.c test as 'hortense' hangs waiting for the
exclusive lock.
Probably just clearing the subpool on error conditions would fix this
specific problem, but why doesn't it fail on a Unix OS? Does exclusive
lock mean the same process/thread can re-lock on Unix? LockFileEx on
Windows is documented to not allow that.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 17:23:05 2005