apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Ruppert ...@myarm.com>
Subject exclusive file access under Windows (Was Re: svn commit: r1534139 - in /apr/apr/branches/1.5.x: ./ CHANGES file_io/win32/readwrite.c)
Date Mon, 21 Oct 2013 16:41:03 GMT
Am 21.10.2013 16:22, schrieb Jeff Trawick:
> On Mon, Oct 21, 2013 at 8:57 AM, <trawick@apache.org
> <mailto:trawick@apache.org>> wrote:
>     Author: trawick
>     Date: Mon Oct 21 12:57:05 2013
>     New Revision: 1534139
>     URL: http://svn.apache.org/r1534139
>     Log:
>     Merge r960671 from trunk:
>     Only deal with the mutex when XTHREAD is enabled. This increases the
>     performance of buffered reads/writes tremendously.
>     * file_io/win32/readwrite.c:
>        (apr_file_read, apr_file_write): only manipulate mutex when XTHREAD
>     Submitted by: Ivan Zhakov <ivan visualsvn.com <http://visualsvn.com>>
> Trunk continues to allocate a mutex if buffered, even if the XTHREAD
> flag is on (a minor detail I suppose).  That presumably is a simple fix
> after double checking all the references to mutex or buffered in the
> code used on Windows.  ISTR other concerns about the mutex or XTHREAD,
> but I think this is an orthogonal issue.

Regarding exclusive access to a file under windows I filed a bug in 
2010: https://issues.apache.org/bugzilla/show_bug.cgi?id=50058

Using the apr_file_lock()/apr_file_unlock() under Windows in append mode 
will deadlock the current thread! In the time of 2010 I just removed the 
apr_file_lock()/apr_file_unlock() code within the readwrite.c module. 
But a better solution is to support nesting within 
apr_file_lock()/apr_file_unlock() API calls!

Any comments?


View raw message