Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 15070 invoked from network); 26 Apr 2010 20:39:06 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 26 Apr 2010 20:39:06 -0000 Received: (qmail 92648 invoked by uid 500); 26 Apr 2010 20:39:05 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 92594 invoked by uid 500); 26 Apr 2010 20:39:05 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 92587 invoked by uid 99); 26 Apr 2010 20:39:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Apr 2010 20:39:05 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [72.167.82.81] (HELO p3plsmtpa01-01.prod.phx3.secureserver.net) (72.167.82.81) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 26 Apr 2010 20:38:56 +0000 Received: (qmail 21162 invoked from network); 26 Apr 2010 20:38:34 -0000 Received: from unknown (76.252.112.72) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 26 Apr 2010 20:38:34 -0000 Message-ID: <4BD5F9C8.707@rowe-clan.net> Date: Mon, 26 Apr 2010 15:38:32 -0500 From: "William A. Rowe Jr." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jeff Trawick CC: APR Developer List , Bert Huijben Subject: Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows References: <002c01cae068$d7e5e970$87b1bc50$@qqmail.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 4/26/2010 2:19 PM, Jeff Trawick wrote: > > So I don't think there's any hidden "reason" why a mutex should always > be obtained on Windows. I too wouldn't be surprised if the fix breaks > some app code somewhere. Keep in mind fd-based operations are atomic on Unix, but not so on windows.