Return-Path: 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 24DAB10D53 for ; Sat, 24 Aug 2013 04:30:51 +0000 (UTC) Received: (qmail 75460 invoked by uid 500); 24 Aug 2013 04:30:50 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 75059 invoked by uid 500); 24 Aug 2013 04:30:47 -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 75050 invoked by uid 99); 24 Aug 2013 04:30:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Aug 2013 04:30:45 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ivan@visualsvn.com designates 74.125.82.41 as permitted sender) Received: from [74.125.82.41] (HELO mail-wg0-f41.google.com) (74.125.82.41) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Aug 2013 04:30:40 +0000 Received: by mail-wg0-f41.google.com with SMTP id c11so2305355wgh.4 for ; Fri, 23 Aug 2013 21:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=visualsvn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iLhPGSSehK+/D8pumIDy78w5lVbEEiOUdcYae7t21zs=; b=f0EPuxbwEAwMpeeLzBDgc6yMuyJlJV1p2Mkbu9g50zt+wDJHqG9izfQo0l3EQ20RdB cWGHGOmx7oE+Xk2u6JBcZqrWT5gHtzeUHupTyhud+10oZ4wc1MQOGx6EdkIbGc+mc/JH 7+yMauFCbmM9VDn6Dzy+Nred3Ts+a3ipGmd1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iLhPGSSehK+/D8pumIDy78w5lVbEEiOUdcYae7t21zs=; b=cBud3zZ8L3eOHpNNN4ACzDOZZD+sLvZTbWwjPUhcKJyIlrlMXJd4gqY7IbY+0snWMl vAeetsOi3/f7Yw1Ipa64XC9jK32qkxAjsh2seBOyWMwlpWZDnueShRq7IGgNY0xclaHb xuJCUvRFzWIwLk+caKI6B8tDnYbQG42klDtvwTn7Q+HWX8b1qttQZigS0A76K/wcIIE2 HBFOXCHuONkUcTR+tTX6baPFa527vRTh5Yshlqi/RDCLx34S1IFyNlnGSV17v/tvmrhb KNzl5wMoAeJMEQE/137Qhbu/U6d+8K6qTOXTiZbrX4nQhIKkSWVa2e92AMROuS57ZBDj 0jOA== X-Gm-Message-State: ALoCoQkrUg+759jkBjJ6KCcMFs/6XDTgOP5OhoHzlg54oE2K06IdnUp0ZVYMHszAzUmL7CcAyh6t X-Received: by 10.180.183.108 with SMTP id el12mr294962wic.55.1377318619629; Fri, 23 Aug 2013 21:30:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.56.35 with HTTP; Fri, 23 Aug 2013 21:29:59 -0700 (PDT) In-Reply-To: <20130823184823.059ff9c2@hub> References: <002c01cae068$d7e5e970$87b1bc50$@qqmail.nl> <4BD5F9C8.707@rowe-clan.net> <036901cae5ee$9e68b5c0$db3a2140$@qqmail.nl> <20130823183935.0e956cd3@hub> <20130823184823.059ff9c2@hub> From: Ivan Zhakov Date: Sat, 24 Aug 2013 08:29:59 +0400 Message-ID: Subject: Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows To: "William A. Rowe Jr." Cc: Jeff Trawick , APR Developer List , Bert Huijben Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org On Sat, Aug 24, 2013 at 3:48 AM, William A. Rowe Jr. wrote: > On Fri, 23 Aug 2013 18:39:35 -0500 > "William A. Rowe Jr." wrote: > >> On Sat, 24 Aug 2013 00:33:38 +0400 >> Ivan Zhakov wrote: >> >> > Actually Windows supports atomic seek-to-end+write: file should be >> > opened with FILE_APPEND_DATA access right only [1] or Offset and >> > OffsetHigh should be 0xFFFFFFFF if overlapped I/O is used [2]. >> > >> > I'm reopening this thread because in Subversion we found case where >> > we need true atomic append across processes/threads. So I'm willing >> > to create a patch implementing atomic append on Windows. Is right >> > idea for APR or not? Any concerns will be very helpful. >> > >> > [1] >> > http://msdn.microsoft.com/en-us/library/windows/desktop/aa363778%28v=vs.85%29.aspx >> > [2] >> > http://msdn.microsoft.com/en-us/library/windows/desktop/aa365747%28v=vs.85%29.aspx >> >> IIRC the difference is that you have writev on unix to atomically >> write multiple buffers. On Windows we fake writev, so your proposed >> atomic writes are no longer atomic. > Subversion doesn't use writev for file I/O, so implementing atomic writes is enough for our case. > Now we might use WriteFileGather at this point (remember, this stuff > was all written when Server 2000 was still around :)... but note that > the compatibility is listed as "Windows Server 2003 [Desktop apps only]. > WTF would that mean? Also not supported for 32 bit Itanium apps running > under WOW64. How bizarre. Then read the description of the > aSegmentArray arg to really break your brain. > WriteFileGather does not help anyway: provided buffers must be at least the size of a system memory page and must be aligned on a system memory page size boundary. -- Ivan Zhakov