On Sun, 3 Apr 2005, [UTF-8] Branko Ä^Libej wrote:
> D.J. Heap wrote:
>
> >On Sun, 2005-04-03 at 09:21 -0600, D.J. Heap wrote:
> >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.
>
Well, the pool is cleared, eventually. We don't clear subpools on error.
I'm going to change this particular case (holding the write lock in FSFS),
since we don't know when the caller will clear the pool and locks should
be released when they're not needed anymore.
Regards,
//Peter
---------------------------------------------------------------------
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:22:38 2005