On Mon, Aug 26, 2013 at 6:43 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > On Sat, 24 Aug 2013 00:33:38 +0400 > Ivan Zhakov <i...@visualsvn.com> wrote: >> > >> > 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 > > This is even worse than I thought... > > 1. we aren't protecting segments of writev within the apr_file_writev > call with the mutex (as Ivan notes) > > 2. the mutex is used for buffered output (which makes sense, if > you have multiple threads with the same apr_file_t context which > write to the same buffer...) > > 3. The mutex -> file lock looks backwards and we release the mutex... > it is a complete mess. > > 4. If the file lock doesn't support nested locks (have yet to check) > then this whole code path is foobar for anyone using the file lock > API within their own code (as would be appropriate for complex > write operations). > > 5. On failure we use pOverlapped with a thread-shared overlapped IO > structure and hEvent signal. This is not unique per-thread and is > clearly a design error if we pass this without holding the mutex. > > I need to go a decade back in svn to pick up the initial principals > and we need to recode both write and writev appropriately. > > If opened for append, unbuffered, non-xthread then I can see us finding > our way to the atomic write-for-append method on unix and windows. But > that method will force us to create the overlapped and hEvent on each > call to write to ensure they are unique per-thread, slowing things down > considerably, in the write failure case. Alternative solution would be take file->lock mutex on write operation and user shared OVERLAPPED structure. Also note that MSDN states that opening file with FILE_APPEND permissions only will perform atomic move-to-end + write without overlapped I/O.
-- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
