Return-Path: 
 <dev-return-25530-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
X-Original-To: apmail-apr-dev-archive@www.apache.org
Delivered-To: apmail-apr-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 65F1A10967
	for <apmail-apr-dev-archive@www.apache.org>;
 Mon, 21 Oct 2013 16:41:36 +0000 (UTC)
Received: (qmail 3357 invoked by uid 500); 21 Oct 2013 16:41:35 -0000
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 3142 invoked by uid 500); 21 Oct 2013 16:41:30 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Id: <dev.apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 3129 invoked by uid 99); 21 Oct 2013 16:41:29 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Oct 2013 16:41:29 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Received: from [85.158.176.213] (HELO server1044-han.de-nserver.de)
 (85.158.176.213)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Oct 2013 16:41:23 +0000
Received: (qmail 26219 invoked from network); 21 Oct 2013 18:41:03 +0200
X-Fcrdns: Yes
Received: from p5DC01780.dip0.t-ipconnect.de (HELO [192.168.0.6])
 (93.192.23.128)
  (smtp-auth username stefan.ruppert@myarm.com, mechanism plain)
  by server1044-han.de-nserver.de (qpsmtpd/0.92) with (CAMELLIA256-SHA
 encrypted) ESMTPSA; Mon, 21 Oct 2013 18:41:03 +0200
Message-ID: <5265591F.4090102@myarm.com>
Date: Mon, 21 Oct 2013 18:41:03 +0200
From: Stefan Ruppert <sr@myarm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: exclusive file access under Windows (Was Re: svn commit: r1534139
 - in /apr/apr/branches/1.5.x: ./ CHANGES file_io/win32/readwrite.c)
References: <20131021125705.7F0C7238899C@eris.apache.org>
 <CAKUrXK5BK4bn7uJutCP8na4pxR7HLE_J3+4o_SM5_Ubx5U_3+Q@mail.gmail.com>
In-Reply-To: 
 <CAKUrXK5BK4bn7uJutCP8na4pxR7HLE_J3+4o_SM5_Ubx5U_3+Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-User-Auth: Auth by stefan.ruppert@myarm.com through 93.192.23.128
X-Virus-Checked: Checked by ClamAV on apache.org

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?

Stefan