On Saturday, August 24, 2013, Branko Čibej wrote: > On 24.08.2013 06:29, Ivan Zhakov wrote: > > On Sat, Aug 24, 2013 at 3:48 AM, William A. Rowe Jr. > > <wr...@rowe-clan.net <javascript:;>> wrote: > >> On Fri, 23 Aug 2013 18:39:35 -0500 > >> "William A. Rowe Jr." <wr...@rowe-clan.net <javascript:;>> wrote: > >> > >>> On Sat, 24 Aug 2013 00:33:38 +0400 > >>> Ivan Zhakov <i...@visualsvn.com <javascript:;>> 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. > > Would that mean that writev on Windows uses a mutex while plain write > does not? How do you avoid a race between write and writev then?
Currently apr_file_writev is alias for calling apr_file_write multiple times without taking lock. Also please note that mutexes helps only if write performed using same file_t in one process, it does not race conditions when write operation from different threads or processes using different handles. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
