apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: 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 18:39:15 GMT
On Mon, Oct 21, 2013 at 12:41 PM, Stefan Ruppert <sr@myarm.com> wrote:

> 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<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?
>
> Stefan
>
>
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?

*IIUC this isn't true for NFS

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Mime
View raw message