On Sat, 24 Aug 2013 00:33:38 +0400 Ivan Zhakov <i...@visualsvn.com> wrote:
> [resurrecting this very old thread, see my reply below] > > On Tue, Apr 27, 2010 at 3:03 PM, Jeff Trawick <traw...@gmail.com> > wrote: > > On Tue, Apr 27, 2010 at 5:47 AM, Bert Huijben <b...@qqmail.nl> > > wrote: > [...] > > >>> On Mon, Apr 26, 2010 at 4:38 PM, William A. Rowe Jr. > >>> <wr...@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.