Am 21.10.2013 20:39, schrieb Jeff Trawick:
On Mon, Oct 21, 2013 at 12:41 PM, Stefan Ruppert <firstname.lastname@example.org<mailto:email@example.com>> wrote:
Am 21.10.2013 16:22, schrieb Jeff Trawick:
On Mon, Oct 21, 2013 at 8:57 AM, <firstname.lastname@example.org
<mailto:email@example.com><mailto:firstname.lastname@example.org <mailto:email@example.com>>> wrote:<http://visualsvn.com> <http://visualsvn.com>>
Date: Mon Oct 21 12:57:05 2013
New Revision: 1534139
Merge r960671 from trunk:
Only deal with the mutex when XTHREAD is enabled. This
performance of buffered reads/writes tremendously.
(apr_file_read, apr_file_write): only manipulate mutex
Submitted by: Ivan Zhakov <ivan visualsvn.com2010: https://issues.apache.org/__bugzilla/show_bug.cgi?id=50058
Trunk continues to allocate a mutex if buffered, even if the XTHREAD
flag is on (a minor detail I suppose). That presumably is a
after double checking all the references to mutex or buffered in the
code used on Windows. ISTR other concerns about the mutex or
but I think this is an orthogonal issue.
Regarding exclusive access to a file under windows I filed a bug in
Using the apr_file_lock()/apr_file___unlock() under Windows injust removed the apr_file_lock()/apr_file___unlock() code within the
append mode will deadlock the current thread! In the time of 2010 Iwithin apr_file_lock()/apr_file___unlock() API calls!
readwrite.c module. But a better solution is to support nesting
I thought it was this simple for append:
On Unix a lock isn't needed because the APR implementation there uses
O_APPEND, which is atomic (subject to the size of the write I suppose)*;
on Windows there's no such feature and APR has to use a lock to make it
equivalent. So the app shouldn't be getting a lock.
Is that consistent with what you see?
The problem arise when you want to use the apr_file_lock()/apr_file_unlock() calls to protected multiple calls to apr_file_write():
Under Unix all works perfect. But under Windows the step 3) call to apr_file_write() will deadlock, because the LockFileEx() should not be called recursively...
However, in the APR API docs there is nothing said about an atomic write within apr_file_write(), thus from my point of view its up to the application to make it atomic with the apr_file_lock()/apr_file_unlock() calls. On Unix its a nice side effect that each call to apr_file_write() is atomic....
The easist way to make it conistent is to support a nesting counter within apr_file_lock()/apr_file_unlock() which will also reflect the APR API docs for that calls which are documented to be used recursively!