apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows
Date Fri, 23 Aug 2013 23:39:35 GMT
On Sat, 24 Aug 2013 00:33:38 +0400
Ivan Zhakov <ivan@visualsvn.com> wrote:

> [resurrecting this very old thread, see my reply below]
> 
> On Tue, Apr 27, 2010 at 3:03 PM, Jeff Trawick <trawick@gmail.com>
> wrote:
> > On Tue, Apr 27, 2010 at 5:47 AM, Bert Huijben <bert@qqmail.nl>
> > wrote:
> [...]
> 
> >>> On Mon, Apr 26, 2010 at 4:38 PM, William A. Rowe Jr.
> >>> <wrowe@rowe-clan.net> wrote:
> >>> > 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.
> >>>
> >>> Since these are buffered files, it doesn't even come down to
> >>> differences in OS file operations; operations on the buffer would
> >>> be the expected failure point.
> >>>
> >>> So the question is whether or not APR expects multi-threaded apps
> >>> sharing a buffered file to turn on the XTHREAD flag.
> >>
> >> Another thing I was thinking about is how the append mode is used.
> >> I can imagine that is used to write to a single logfile in a
> >> multithreaded application. (But if we don't enable the mutex on
> >> other operating systems, it should probably be fixed in the
> >> application)
> >
> > Append is special, in that POSIX has an append flag on open() which
> > handles atomicity of seek-to-end+write; so that mutex isn't needed
> > on all operating systems.  This is a case where Windows needs a
> > mutex but Unix doesn't.
> 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.

Mime
View raw message